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PREFACE 


This  volume  contains  the  addendum  of  the  handbook  on  procedures  for 
estimating  con?>uter  system  sizing  and  timing  parameters  during  the 
acquisition  life-cycle  of  Embedded  Computer  Systems  (ECS) .  The  handbook, 
of  which  this  volume  is  a  part,  was  developed  for  use  by  the  engineers  and 
computer  scientists  of  the  Electronic  Systems  Division's  Computer  Systems 
Engineering  Directorate  (ESD/TOI). 

The  addendum  contains  supplemental  information  pertaining  to  selected 
ESD  C3  Embedded  Computer  Systems  (ECS)  that  is  presented  to  illustrate 
the  types  of  data  that  could  be  considered  in  the  development  of  computer 
system  analogies  for  sizing  and  timing  studies.  Also  included  are  a 
number  of  graphic  representations  of  computer  system  sizing  and  timing 
relationships  that  are  based  on  algorithms  developed  by  various  computer 
scientists  during  the  past  several  years.  Although  the  relationships  are 
presented  in  absolute  values,  users  are  cautioned  not  to  consider  any 
relationship  by  itself.  Rather,  they  should  only  be  considered  additional 
possible  data  points  in  the  overall  evaluation  of  a  computer  system's 
sizing  and  timing  parameters.  Also  included  are  two  examples  of  the 
application  of  the  procedures  discussed  in  Volume  I,  a  proposed  revision 
of  the  Data  Item  Description  (DID)  entitled,  Computer  Program  Timing  and 
Sizing  Data  (DI-S- 305681 ,  and  a  list  of  suggestions  for  future  work  to 
update  and  improve  the  estimating  procedures. 


The  handbook  consists  of  two  volumes,  the  first  volume  discusses 
procedures  and  techniques,  and  this  second  volume  provides  an  addendum  of 
supplemental  information.  The  primary  features  and  tools  are  as  follows: 
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1.  INTRODUCTION 


I. 1  Background. 

For  each  new  generation  of  Command,  Control,  and  Communications  (C3) 
systems,  Embedded  Computer  Systems  (ECS)  become  increasingly  critical. 
There  are  many  reasons  for  this;  computer  systems,  including  software,  are 
performing  more  functions  more  rapidly,  and  they  must  be  reliable  under 
more  extreme  physical  and  operational  constraints.  As  more  stringent 
requirements  have  been  imposed  upon  Command,  Control  and  Communications 
(C3)  system  performance  (e.g.,  more  targets  and  target  types,  more 
sophisticated  signal  processing,  improved  countermeasures  and  counter¬ 
countermeasures,  faster  responses,  and  greater  reliability) ,  increasing 
demands  have  been  placed  upon  the  C 3  computer  systems. 

In  many  system  acquisitions,  the  uncertainties  of  qualifying  and 
quantifying  the  hardware  and  software  needs  of  an  ECS  have  been  extensive, 
with  software  uncertainties  far  exceeding  those  of  the  hardware.  This 
situation  is  projected  to  increase  in  frequency  and  severity  in  the 
future.  The  requirement  to  perform  most  necessary  functions  in  real-time 
is  very  demanding  and  has  thus  provided  the  impetus  for  continued 
improvement  in  hardware  and  software  technologies.  However,  in  spite  of 
these  technological  improvements,  increased  operational  requirements 
continue  to  dictate  larger  and  more  sophisticated  computer  systems  and 
software  packages.  As  a  consequence,  there  is  an  increasing,  if  not 
urgent,  need  to  develop  and  evaluate  embedded  computer  systems  sizing  and 
timing  estimates. 

The  field  of  computer  system  acquisition  management  and  engineering  is 
just  developing,  especially  in  its  ability  to  derive  sizing  and  timing 
estimates  for  entire  computer  systems  and  software  in  the  overall  computer 
system  environment.  Sizing  and  timing  of  whole  or  large  segments  of 
computer  systems  are  particularly  complex  and,  at  the  present  state-of- 
the-art,  only  appear  feasible  using  models,  simulations,  benchmarks  or 
monitors.  The  primary  difficulty  is  the  definition  of  a  workload  that  a 
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computer  system  or  subsystem  must  perform.  Additionally,  the  following 
difficulties  in  sizing  and  timing  computer  systems  have  been  acknowledged: 


•  lack  of  standard  engineering  and  management  procedures 
and  techniques, 

•  lack  of  standard  metrics  used  in  developing  estimates, 

•  lack  of  understanding  the  relationships  between  hard¬ 
ware  and  software  characteristics  and  operational 
requirements, 

•  lack  of  accurate  or  timely  projections  of  hardware  and 
software  resource  requirements,  and 

•  lack  of  awareness  of  viable  system  design  and  techno¬ 
logical  advances. 


The  Department  of  Defense,  recognizing  these  deficiencies,  established 
the  DoD  Management  Steering  Committee  for  embedded  computer  resources.  As 
stated  in  the  background  section  of  the  charter  in  DoD  Directive  5000.29 
for  the  group: 


...Current  annual  expenditures  by  the  Department  of 
Defense  on  the  design,  development,  acquisition, 
management  and  operation  support  of  computer  resources 
embedded  within  and  integral  to  weapons,  communi¬ 
cations,  command  and  control,  and  intelligence  systems 
are  measured  in  the  billions  of  dollars.  At  the  same 
time,  such  computer  resources  have  often  presented 
critical  cost  and  schedule  problems  during  the  develop¬ 
ment  and  acquisition  of  new  defense  systems.  Even 
after  system  implementation  and  fielding,  the  software 
has  often  proven  unreliable... 


Computer  system  resource  estimating  has  historically  been  charac¬ 
terized  by  two  shortcomings;  it  has  been  poorly  done  and  seldom  vali¬ 
dated.  The  reasons  for  poor  estimating  are  numerous.  The  lack  of 
necessary  information  resources  to  implement  reliable  estimating 
methodologies  is  among  the  most  important,  also: 

•  There  is  no  common  data  base  from  which  to  develop 
computer  resource  estimates. 
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•  Even  where  some  historical  computer  systems  data  exist, 
there  is  often  no  clear  understanding  of  what  the  data 
actually  represent. 

The  problems  associated  with  embedded  computer  system  sizing  and 
timing  estimates  are  more  pronounced  and  diverse  than  those  associated 
with  stand-alone  systems.  When  a  C3  system  is  developed  with  integrated 
embedded  computers,  there  is  often  concurrent  hardware/software  develop¬ 
ment.  An  immediate  problem,  therefore,  is  that  there  may  be  no  function¬ 
ing  hardware  on  which  to  begin  software  integration.  The  concepts  of 
early  defect  removal  using  modern  programming  practices  may  be  less  than 
adequate  to  prevent  severe  software  or  hardware  problems  when  the  system 
is  completed.  Estimates  can  be  done  by  use  of  models,  simulations, 
benchmarks  or  monitoring;  however,  these  techniques  may  not  be  feasible 
due  to  costs,  time  constraints,  or  lack  of  relevant  data. 

The  above  discussion  of  the  background  highlights  some  of  the  major 
problems  and  concerns  regarding  estimation  of  computer  system  sizing  and 
timing  parameters.  It  also  demonstrates  the  critical  need  for  Air  Force 
managers  to  acquire  standardized  engineering  and  management  procedures, 
now  presented  in  this  handbook,  to  insure  that  the  operational  require¬ 
ments  of  C3  ECS  are  met  during  the  system  acquisition  life-cycle  in  the 
most  efficient  and  effective  manner. 

1. 2  Goal  and  Content. 

The  main  emphasis  of  this  handbook  is  to  provide  standard  procedures 
rather  than  metrics  for  estimating  sizing  and  timing  parameters  of  ECS  in 
Air  Force  C3  systems,  for  use  by  the  engineers  and  computer  scientists 
of  the  Electronic  Systems  Division's  Computer  Systems  Engineering 
Directorate  (ESD/TOI).  Such  use  should  enable  the  engineers  and  computer 
scientists  of  ESD/TOI  to  better  assist  other  personnel  at  ESD  in 
conducting  sizing  and  timing  studies.  IN  THE  EVENT  ESD  PERSONNEL  HEED 
ASSISTANCE  IN  CONDUCTING  A  SIZING  AND  TIMING  STUDY  -  CONTACT  ESD/TOI. 
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This  haridbook  consists  of  two  volumes;  the  first  volume  contains  the 
procedures  and  techniques,  and  this  second  volume  provides  an  addendum  of 
supplemental  information.  In  the  first  volume,  the  procedures  structure 
the  function  of  estimating  ECS  sizing  and  timing  into  three  types: 
initial  studies,  study  updates,  and  developmental  monitoring,  and  provide 
a  step-by-step  program  employing  many  of  the  techniques  used  in  Validation 
and  Verification  (V&V)  of  systems.  The  procedural  steps  are  discussed 
with  emphasis  on  actions  that  should  be  taken,  risks  that  should  be 
considered,  constraints  that  may  be  encountered,  and  factors  that  affect 
the  quality  of  an  estimate  at  various  stages  of  the  acquisition. 
Techniques  that  can  be  used  in  estimating  sizing  and  timing  parameters  at 
various  stages  of  the  acquisition  are  discussed.  The  technique  discus¬ 
sions  include  general  information  regarding  required  data,  assumptions, 
application,  and  level  of  confidence.  In  this  second  volume,  information 
about  selected  ESD  ECS  is  presented  to  illustrate  the  types  of  data 
that  could  be  considered  in  the  development  of  computer  system  analogies 
for  sizing  and  timing  studies.  Also  included  are  a  number  of  graphically 
illustrated  computer  system  sizing  and  timing  relative  relationships  that 
are  based  on  algorithms  developed  by  various  computer  scientists.  In 
addition,  there  are  two  examples  th3t  discuss  the  application  of  the 
procedures. 

1.3  Organization  of  this  Volume. 

The  organization  of  the  remainder  of  this  volume  is  as  follows:  Tab  A 
provides  illustrative  information  about  selected  ESD  c3  ECS;  Tab  B 
presents  graphic  representations  of  computer  system  relationships;  Tab  C 
contains  two  examples  of  the  application  of  procedures;  Tab  D  presents  a 
proposed  revision  of  DID  (DI-S-30568)  ;  Tab  E  contains  a  list  of 
suggestions  for  future  work  to  update  and  improve  the  estimating 
procedures;  and  in  addition,  there  is  a  reference  listing,  an  annotated 
bibliography,  and  an  index  for  use  with  this  handbook. 


TAB  A  COMPUTER  SYSTEMS 


This  tab  is  provided  for  illustrative  purposes  only,  and  contains  two 
sections  of  information  relative  to  ESD  C3  Embedded  Computer  Systems 
(ECS)  .  Information  of  this  type  could  be  useful  in  the  application  of 
analogy  techniques.  The  first  section  provides  a  sample  listing  of  ESD 
C3  major  projects.  The  second  section  presents  a  sample  listing  of 
generalized  computer  equipment  specifications  for  some  ESD  systems. 

The  Sample  ESD  c3  Major  Projects,  Section  1,  lists  ESD  C^  projects 
alphabetically,  gives  a  brief  description  of  the  project's  objectives,  and 
lists  the  major  hardware  components  of  each  system. 

The  Sample  Generalized  Computer  Equipment  Specifications  for  Some  ESD 
Systems,  Section  2,  presents  descriptions  and  specifications  relevant  to 
systems  cited  in  Section  1  and  are  in  alphabetical  order  by  manufacturer. 


The  following  is  an  index  to  Tab  A,  Sections  1  and  2. 


Section  1:  Sample  ESD  C3  Major  Projects 

Page 


Air  Force  Satellite  Communications  System  1205  .  1-3 

Air  Force  World  Wide  Military  Command  and  Control  System 

( AFWWMCCS)  .  1-3 

COBRA  DANE  633A .  1-3 

COMBAT  GRANDE  .  1-4 

Combat  Theater  Communications  478T  1-4 

CONUS  Over-the-Hor izon  Backscatter  Radar  414L  .  1-4 

E-3A  Airborne  Warning  and  Control  System  (AWACS)  411L  .  .  .  1-4 

E-4  Airborne  Command  Post  481B .  1-5 

Joint  Surveillance  System  (JSS)  968H  .  .....  1-5 

Joint  Tactical  Information  Distribution  System  634B  ....  1-5 

NORAD  Cheyenne  Mountain  Complex  Improvements  427M  .....  1-6 

PAVE  PAWS  2059  1-6 

SAC  Digital  Information  Network  (SACDIN)  1136  .  1-6 

Tactical  Air  Control  System  improvements  (TACSI)  485L  .  .  .  1-7 
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Section  2:  Sample  Generalized  Computer  Equipment  Specifications 
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Control  Data  Corporation  (CDC)  Cyber  74  .  2-3 

Control  Data  Corporation  (CDC)  Cyber  174-12  .  2-5 
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TAB  A 

SECTION  1  SAMPLE  ESD  C3  MAJOR  PROJECTS 


The  following  information  on  ESD  projects  is  illustrative  only.  The 
projects  are  dynamic  and  subject  to  change. 
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SECTION  1  SAMPLE  ESD  C3  MAJOR  PROJECTS 

Air  Force  Satellite _ Communications  System _ 120?.  Acquisition  of  rjHF 

airborne/ground  force  terminals,  airborne/ground  command  post  terminals, 
ancillary  equipment  for  operational  control  and  communicat ions 
transponders  on  selected  Air  Force  satellites.  The  associated  family  of 
modular  UHF  transceivers  will  provide  a  command  communications  capability 
in  the  line-of-sight  mode.  The  full-grown  family  of  modular  'JHF  radios 
will  result  in  a  common  base  to  provide  the  transceiver  for  the  satellite 
SIOP  and  Force  communications  terminals. 

This  system  consists  of: 

•  2  ROLM  1603  minicomputers  in  a  multiprocessor  mode. 

•  1  each,  magnetic  tape  cartridge  extended  memory,  processor 
control  unit,  and  status  display  unit. 


Air  Force  World  Wide  Military  Command  and  Control  System  (AFWWMCCS) . 
Involves  systems  planning  and  engineering  for  Air  Force  elements  of  the 
World  Wide  Military  Command  and  Control  System.  Activities  will  focus  on 
intersystem  engineering  of  selected  AFWWMCCS  existing  and  planned  assets. 

This  system  consists  of: 

•  Honeywell  H-60S0  computer  systems. 

•  Honeywell  H-6060  computer  systems. 

•  Honeywell  H-6080  computer  systems. 

•  Honeywell  H-716  minicomputers  for  communications 

and  I/O  controllers. 


COBRA  DANE  63 3A.  Installation  of  a  phased  array  radar  on  Shemya  AFS, 
Aleutian  Islands,  to  collect  intelligence  data  of  Soviet  missile 
development  tests.  Corollary  missions  are  early  warning  and  satellite 
tracking. 

This  system  consists  of: 

•  1  Control  Data  Corporation  (CDC)  Cyber  74-18  with  5  CDC  243-2 
display  consoles. 

•  1  Raytheon  RDS-500  minicomputer. 

•  1  Digital  Equipment  Corporation  PDP-11,  receives  post  mission 
processing  output  at  FTD  and  prepares  tape  for  U-1108. 

•  1  UNIVAC  U-1108  at  FTD. 

•  1  Intel  8080,  acts  as  a  communications  controller. 

•  1  CDC  Cyber  74-14. 


COMBAT  GRANDE.  Insure  maintenance  of  Spanish  Air  Force  air  defense 
system.  Provide  additional  communication  links  for  the  network  and 
improve  existing  communications,  command  and  control,  and  weapons  control. 

This  system  consists  of: 

•  2  Hughes  Aircraft  Corp.  H-5118  computers,  one  used  as  the  main 
processing  and  the  other  as  backup. 

•  37  Texas  Instruments  TI-980A  minicomputers,  28  as  display  console 
controllers,  2  as  primary  and  backup  display  system  controllers, 
and  7  remotely  located  at  the  7  long  range  radar  sites. 

•  4  Digital  Equipment  Corporation  PDP-11/05  minicomputers  for  call 
processing  and  control  within  the  PABX. 


Combat  Theater  Communications  478T.  Acquisition  of  a  new  hybrid 
analog/digital  and  digital  communications  equipment  both  for  Air  Force 
unique  tactical  requirements  and  for  the  DOD  Joint  Tactical  Communications 
(TRI-TAC)  Program.  Within  the  TRI-TAC  Program,  the  478T  office  carries 
out  the  development,  test,  and  production  of  equipment  assigned  as  Air 
Force  responsibility  and  insures  that  USAF  requirements  are  met  by  all  of 
the  equipment  procured  through  this  joint  service  program.  Also 
responsible  for  the  interoperability  of  TRI-TAC  equipment  with  other 
communications  equipment  within  the  tactical  Air  Force  environment. 

This  system  consists  of: 

•  UNIVAC  U-1600  (same  as  AN/UYK-20)  central  processor  with  a 
microprocessor  data-base  controller  and  I/O  controller,  visual 
display  units  (VDU's),  magnetic  tape  units,  discs,  and  line 
printers. 


CONUS  Over-the-Hor izon  Backscatter  Radar  414L.  Provides  long-range 
detection  of  aircraft  approaching  North  America  as  part  of  the  NORAD  air 
surveillance  and  warning  capability.  Distinguishing  technical  feature  of 
OTH-B  is  its  ability  to  detect  targets  at  all  altitudes  and  at  extended 
ranges.  The  present  program  is  to  build  and  test  a  prototype. 

This  system  consists  of: 

•  1  UNIVAC  U-1110  computer  and  peripherals. 

•  2  UNIVAC  U-1600  minicomputers  and  peripherals. 

•  1  General  Electric  special  purpose  signal  processor. 

•  Hazeltine  display  equipment. 


E-3A  Airborne  Warning  and  Control  System  411L.  Provides  survivable 
airborne  air  surveillance  capability  and  command,  control,  and 
communications  functions.  Its  distinguishing  technical  feature  is  the 
capability  to  detect  and  track  aircraft  operating  at  high  and  low 
altitudes  over  both  land  and  water.  Used  by  the  Tactical  Air  Command  with 
Tinker  APB  as  the  main  operating  base,  aircraft  may  deploy  throughout  the 
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United  States  and  overseas  to  provide  surveillance,  warning  and  control  in 
a  variety  of  peacetime  and  wartime  situations. 

In  each  aircraft  is/are: 

•  1  IBM  4  Pi  CC-1  computer  for  applications  program. 

•  1  Northrop  NOC  1070  minicomputer  for  navigation. 

•  2  Delco  Magic  311  minicomputers  for  navigation. 

•  1  Westinghouse  radar  data  correlator. 

•  1  IBM  4  Pi  AP-1A  for  TDMA  communication  terminal  control. 

Ground  support  consists  of: 

•  1  IBM  370/155. 

•  1  Redifon  200A  for  flight  simulator. 


E-4  Airborne  Command  Post  48 IB.  Provides  the  National  Military  Command 
System  (NMCS)  and  Stragetic  Air  Command  (SAC)  with  an  airborne  command  and 
control  system  that  will  operate  during  the  pre-,  trans-,  and  post-attack 
phases  of  a  general  war.  As  a  survivable  emergency  extension  of  NMCS  and 

SAC  ground  command  control  centers,  provides  high  confidence  in  our 

ability  to  execute  and  control  SIOP  forces  during  nuclear  war. 

In  each  aircraft  is/are: 

•  A  Burroughs  D-machine  used  as  communications  processor. 

•  2  EECO  paper  type  readers. 

•  2  Potter  magnetic  tape  units. 

•  2  Data  Magic  line  printers. 

Ground  support  consists  of: 

•  1  each.  Burroughs  keyboard/printer,  disc,  card  reader, 
keyboard/CRT  terminal,  and  EECO  paper  tape  reader  &  punch. 

Joint  Surveillance  System  (JSS)  968H.  The  JSS  program  has  been 

established  to  acquire  and  deploy  a  peacetime  air  surveillance  and  control 
system  to  replace  the  Semi-Automatic  Ground  Environment  (SAGE)  system  for 
the  U.S.  and  Canada.  For  Canada,  the  mission  is  expanded  to  include 
support  of  wartime  air  defense  functions  and  in  Alaska  the  mission 

includes  the  performance  of  tactical  air  control  functions. 

This  system  consists  of: 

•  1  large  computer  complex  and  20  to  30  display  consoles  at  each 
RDCC. 


Joint  Tactical  Information  Distribution  System  634B.  A  program  to 
develop  a  high  capacity,  reliable,  jam-protected,  secure,  digital 
information  distribution  system  which  will  provide  an  unprecedented  degree 
of  interoperability  between  data  collection  elements,  combat  elements,  and 
command  and  control  centers  within  a  military  theater  of  operations. 
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This  system  consists  of: 

•  3  ASIT's,  one  for  each  Tactical  Data  Information  Link,  TADIL-A, 
TADIL-B,  TADIL-C. 

•  Translator  Processor  (TP)  might  be  an  AN/UYK-20  (same  as  Air 
Force  U-1600  by  UNIVAC)  or  equivalent. 


NORAD  Cheyenne  Mountain  Complex  Improvements  427M.  Acquisition  of  data 
processing  equipment,  software,  displays,  and  communications  for  the  NORAD 
Cheyenne  Mountain  Complex.  The  Core  Processing  Segment,  Modular  Display 
Segment,  and  the  Communications  System  Segment  will  provide  NORAD  with  an 
integrated,  responsive  capability  and  a  growth  potential  over  a  projected 
10-year  life  span  without  major  changes  to  equipment  or  software. 

This  system  consists  of: 

•  2  Honeywell  H-6050  computers. 

•  6  Data  General  NOVA  840  minicomputers. 

•  3  Honeywell  H-6080  computers. 

•  2  Honeywell  H-716  minicomputers. 

•  3  Honeywell  Datanet  355  processors. 

•  3  SSF  alphanumeric  consoles. 

•  4  Data  General  NOVA  840  interface  processors. 

•  1  Data  General  DAPT  graphics  processor. 

•  40  Data  General  NOVA  1220  NCMC  display  controllers  and  displays. 

•  11  non-interactive  displays. 

PAVE  PAWS  20 59 .  Two  dual-faced  phased  array  radars,  one  to  be  deployed 
on  the  East  Coast  and  one  of  the  West  Coast.  This  system  will  be  operated 
by  the  Aerospace  Defense  Command  and  will  provide  warning  to  the  National 
Command  Authority  of  a  sea-launched  ballistic  missile  attack  against  the 
Continental  United  States. 

This  system  consists  of: 

•  2  Control  Data  Corporation  (CDC)  Cyber  174-12  computers. 

•  3  CDC  System  17  display  processors. 

•  6  CDC  777  displays,  6  tape  drives,  4  disc  units. 


SAC  Digital  Information  Network  (SACDIN)  1136.  A  program  for  an 
integrated  SAC  command-wide  digital  record  communications  system  to  meet, 
with  updating,  the  requirements  for  command-control  and  support  data 
transmission  into  the  1990s. 

This  system  consists  of: 

•  5  Subnet  Communication  Processors  (SCP) 

•  32  Base  Communications  Processors  (BCP) 

•  26  Missile  Base  Communications  Processors  (MBCP) 

•  150  User  Terminal  Elements  (UTE) . 
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Tactical  Air  Control  System  Improvements  (TACSI)  485L.  This  program  will 
give  the  Tactical  Air  Control  System  (TACS)  increased  operational 
capabilities  needed  for  combat  command  and  control  of  tactical  aerospace 
operations.  Improvements  consist  of  mobile  communications  and  electronic 
systems  capable  of  modular  world-wide  deployment  that  are  compatible  with 
the  TACS  and  interoperable  with  Army,  Navy,  and  Marine  Corps  tactical  data 
systems. 

This  system  consists  of: 

•  UNIVAC  AN/UYK-7  computers  for  data  processing  and  display 

•  Control  Data  Corporation  (CDC)  AN/UYK-25  computers  for 
communications  processors. 

•  CDC  UYK-25  for  data  source  terminals. 
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GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 

The  following  information  is  generalized  data  based  on  manufacturer's 
specifications.  This  equipment  is  used  in  the  ESD  system(s)  cited  in  the 
comments,  though  configuration  may  actually  vary. 


MANUFACTURER  &  MODEL 


Control  Data  Corporation  Cyber  74 


DATA  FORMAT 
Word  length  (bits) 

Fixed  point  operand  (bits) 

Instruction  length  (bits) 

Floating  point _ 

MAIN  STORAGE 
Type 

Cycle  time  (microseconds) 
Capacity  (words) 

Increments  (words) 

Inter  leaving 

Buffer  (cache)  storage 

Extended  memory 

CENTRAL  PROCESSOR 
CPU  configuration 
Registers 


No.  directly  addressable  words 
Indirect  addressing 
Machine  cycle  time 
Instruction  time  (microseconds) 


Hardware  functional  units 


Real-time  clock  or  timer _ 

INPUT/OUTPUT  CONTROL 
I/O  word  size  (bits) 

Maximum  I/O  rate  { words/second) 
No.  external  interrupt  levels 
Number  I/O  channels 


60  in  CPU  &  main  storage,  12  in  peripheral 
processors's  &  I/O's 
60  or  18  in  CPU;  6,  12,  or  18  in 
peripherals 

15  or  30  in  CPU,  12  or  24  in  peripherals 
Yes _ 

Magnetic  core 
1.0  per  word 

32K  to  131K  (Dual  processors  start  at  65K) 
4K  banks 

Maximum  data  rate  10M  words  per  second 

Magnetic  core,  up  to  2M  words  in  125K 
blocks,  3.2  microseconds  per  8  word  record 

Can  dual  with  a  Cyber  73  unified  CPU 
8-60  bit  operand  (instruction  stack), 

8-18  bit  address,  8-18  bit  index;  64  index 
registers  in  peripherals 

Not  in  CPU,  one  level  in  peripherals 

.3  fixed  add,  .4  float  add,  1.0  multiply, 
2.9  divide:  typical  MIPS:  3  for  single, 
3.7  for  dual; 

10  independent,  concurrent  units: 

2  increment,  2  multiply,  1  each:  add, 
long  add,  shift,  divide,  Boolean  algebra, 
and  branch 


12  or  24  (all  computer  to  computer 
capable) 


A2-3 


GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 


CDC  Cyber  74  (continued) 


PERIPHERAL  EQUIPMENT 

i - 

Disc  pack  storage 

Up  to  8  handlers  per  controller,  up  to 

118M  6  bit  characters  per  handler 

Non-interchangeable  disc  storage 

Yes 

Drum  storage 

No 

Magnetic  tape 

7  or  9  Track,  8  models,  37.5  to  150  inches 

per  second,  200  to  1600  bits  per  inch 

Punched  card 

Up  to  1200  cards  per  minute  read 

Paper  tape 

Printer  speed 

Up  to  1200  lines  per  minute 

Terminals 

Synchronous  or  Asynchronous 

Other 

COMMENTS:  Two  systems  used  in  Cobra  Dane  have  5  display  consoles. 
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GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 

The  following  information  is  generalized  data  based  on  manufacturer's 
specifications.  This  equipment  is  used  in  the  ESD  system(s)  cited  in  the 
comments,  though  configuration  may  actually  vary. 


MANUFACTURER  £  MODEL  Control  Data  Corporation  Cyber  174-12 


DATA  FORMAT 

Word  length  (bits) 

60  in  CPU  and  main  storage,  12  in  peri¬ 
pheral  processor's  and  I/O's 

Fixed  point  operand  (bits) 

60  or  18  in  CPU;  6,  12,  or  18  in 
peripherals 

Instruction  length  (bits) 

15  or  30  in  CPU,  12  or  24  in  peripherals 

Floating  point 

Yes 

MAIN  STORAGE 

Type 

Metal  Oxide  Semiconductor 

Cycle  time  (microseconds) 

0.4  per  word 

Capacity  (words) 

65K  to  262K 

Increments  (words) 

32K  banks 

Inter  leaving 

8  banks  gives  a  0.05  microsecond  effective 
cycle  time 

Buffer  (cache)  storage 

NO 

Extended  memory 

Magnetic  core,  up  to  2M  words  in  125K 
word  banks,  3.2  microseconds  per  8  word 
record  fetch 

CENTRAL  PROCESSOR 

CPU  configuration 

The  174  CPU  is  actually  2  CDC  Cyber  173 
CPU's 

Registers 

8  60  bit  operand,  8  18  bit  address, 

8  18  bit  index 

No.  directly  addressable  words 
Indirect  addressing 

Machine  cycle  time 

Not  used  in  CPU,  one  level  in  peripherals 

Instruction  time  (microseconds) 

Fixed  point  add  0.25 

Hardware  functional  units 

Unified  arithmetic  unit  performs  all 
instructions 

Real-time  clock  or  timer 

INPUT/OUTPUT  CONTROL 

I/O  word  size  (bits) 

12 

Maximum  I/O  rate  (words/second) 

4M  6  bit  characters  per  second 

No.  external  interrupt  levels 
Number  I/O  channels 

12  or  24 

PERIPHERAL  EQUIPMENT 

Disc  pack  storage 

Up  to  8  handlers  per  controller,  up  to 

237M  characters  per  handler 

Non-interchangeable  disc  storage 
Drum  storage 

No 
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GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 


CDC  Cyber  174-12  (continued) 


PERIPHERAL  EQUIPMENT  (continued) 

Magnetic  tape 

7  or  9  track,  8  models,  up  to  200  inches 

per  second,  up  to  1600  bits  per  inch 

Punched  card 

Reads  up  to  1200  cards  per  minute,  punches 

up  to  250  cpm 

Paper  tape 

Printer  speed 

Up  to  2000  lines  per  minute 

Terminals 

Synchronous  /asynchronous 

Other 

Communications  processor 

COMMENTS:  Has  a  two  word  overlap  or  lookahead  in  the  instruction  stack. 

Two  systems  used  in  PAVE  PAWS  with  3  display  peripheral 
processors,  6  CDC  777  displays,  6  tape  drives,  and  4  disc 
units. 
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GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 

The  following  information  is  generalized  data  based  on  manufacturer's 
specifications.  This  equipment  is  used  in  the  ESD  system(s)  cited  in  the 
comments,  though  configuration  may  actually  vary. 


MANUFACTURER  &  MODEL 


Control  Data  Corporation  System  17 


DATA  FORMAT 

Word  length  (bits) 

Fixed  point  operand  (bits) 
Instruction  length  (bits) 

Floating  point 

16+2  (Parity) 

16 

16  or  32 

MAIN  STORAGE 

Type 

Metal  Oxide  Semiconductor 

Cycle  time  (microseconds) 

0.6  or  0.9 

Capacity  (words) 

4K  to  16K  words 

Increments  (words) 

Interleaving 

Buffer  (cache)  storage 

Extended  memory 

CENTRAL  PROCESSOR 

CPU  configuration 

Registers 

2  accumlators;  2  index 

No.  directly  addressable  words 

256 

Indirect  addressing 

Multi-level 

Machine  cycle  time 

Instruction  time  (microseconds) 

Full  word  add  time  1.2  or  1.8 

Hardware  functional  units 

Standard  multiply  and  divide;  optional 

byte  manipulation 

Real-time  clock  or  timer 

Optional 

INPUT/OUTPUT  CONTROL 

I/O  word  size  (bits) 

16 

Maximum  I/O  rate  (words/second) 

1.6M 

No.  external  interrupt  levels 

2  to  16 

Number  I/O  channels 

PERIPHERAL  EQUIPMENT 

Disc  pack  storage 

Yes 

Non-interchangeable  disc  storage 

Yes 

Drum  storage 

Yes 

Magnetic  tape 

Up  to  60K  characters  per  second 

Punched  card 

Up  to  1600  cards  per  minute  input  and 

460  out 

Paper  tape 

Up  to  400  characters  per  second  in  and 

150  out 

Printer  speed 

Terminals 

CRT 

Other 

Optical  Character  Reader,  analog  to 

digital  converters 
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GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 
CDC  System  17  (continued) 


COMMENTS 


Three  units  used  as  display  processors  in  PAVE  PAWS. 


GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 

The  following  information  is  generalized  data  based  on  manufacturer's 
specif ications.  This  equipment  is  used  in  the  ESD  system(s)  cited  in  tne 
comments,  though  configuration  may  actually  vary. 


MANUFACTURER  &  MODEL  Control  Data  Corporation  AN/UYK-25  MP60 


DATA  FORMAT 

Word  length  (bits) 

32 

Fixed  point  operand  (bits) 

32 

Instruction  length  (bits) 

32 

Floating  point 

standard 

MAIN  STORAGE 

Type 

Magnetic  core,  36  bits  (with  error 

correction  code) 

Cycle  time  (microseconds) 

1 

Capacity  (words) 

32K  -  500K 

Increments  (words) 

32K,  65K 

Interleaving 

No 

Buffer  (cache)  storage 

Microstore  -  4K;  0.17  microsecond  cycle 

RAM 

Extended  memory 

NO 

CENTRAL  PROCESSOR 

CPU  configuration 

Single  processor  or  up  to  8  CPU's  in  an 

array 

Registers 

256  general  purpose 

No.  directly  addressable  words 

512K 

Indirect  addressing 

Yes 

Machine  cycle  time 

Instruction  time  (microseconds) 

Fixed  point  add  2.2 

Hardware  functional  units 

Standard:  float  point,  fix  point  add  and 

subtract,  multiply  and  divide,  byte/bit 

manipulation,  literal  instructions 

Real-time  block  or  timer 

Optional 

INPUT/OUTPUT  CONTROL 

I/O  word  size  (bits) 

16 

Maximum  I/O  rate  (words/second) 

62. 5K 

No.  external  interrupt  levels 

128 

Number  I/O  channels 

16  per  I/O  controller,  up  to  4  I/O 

controller 's 

PERIPHERAL  EQUIPMENT 

Disc  paCk  storage 

872M  bit  per  handler,  8  handlers  per 

controller 

Non-interchangeable  disc  storage 

1000M  bit  per  handler,  up  to  6  handlers 

Drum  storage 

NO 

Magnetic  tape 

7  or  9,  up  to  1600  bits  per  inch,  up  to 

200  inches  per  second 
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GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 
CDC  AN/UYK-25  (continued) 


PERIPHERAL  EQUIPMENT  (continued) 

Punched  card 

1500  cards  per  minute  in;  250  cards  per 

minute  out 

Paper  tape 

600  characters  per  second  in;  100 

characters  per  second  out 

Printer  speed 

2000  lines  per  minute 

Terminals 

TTY,  asynchronous  CRT 

Other 

OCR,  analog  to  digital  converter. 

graphics,  communications 

COMMENTS:  Two  systems  used  in  TACSI:  one  as  a  communications  processor 
and  the  other  as  a  data  source  terminal  controller. 


GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 


The  following  information  is  generalized  data  based  on  manufacturer's 
specifications.  This  equipment  is  used  in  the  ESD  system(s)  cited  in  the 
comments,  though  configuration  may  actually  vary. 


MANUFACTURER  &  MODEL  Data  General  NOVA  840 


DATA  FORMAT 

Word  length  (bits) 

16 

Fixed  point  operand  (bits) 

16 

Instruction  length  (bits) 

16 

Floating  point 

Optional 

MAIN  STORAGE 

Type 

Magnetic  core 

Cycle  time  (microseconds) 

0.8 

Capacity  (words) 

16K  to  131K 

Increments  (words) 

Inter  leaving 

Buffer  (cache)  storage 

Extended  memory 

CENTRAL  PROCESSOR 

CPU  conf iguration 

Single  processor 

Registers 

4  accumulator,  2  index 

No.  directly  addressable  words 

1,024 

Indirect  addressing 

Multi-level 

Machine  cycle  time 

Instruction  time  (microseconds) 

Full  word  add  time  0.8 

Hardware  functional  units 

Standard:  byte  manipulation;  optional: 

multiply  and  divide,  floating  point 

Real-time  clock  or  timer 

Optional 

INPUT/OUTPUT  CONTROL 

I/O  word  size  (bits) 

16 

Maximum  I/O  rate  (words/second) 

1.25M 

No.  external  interrupt  levels 

16 

Number  I/O  channels 

PERIPHERAL  EQUIPMENT 

Disc  pack  storage 

Yes 

Non-interchangeable  disc  storage 

Yes 

Drum  storage 

No 

Magnetic  tape 

60K  characters  per  second  maximum 

Punched  card 

Reads  up  to  1000  cards  per  minute 

Paper  tape 

Reads  up  to  400  characters  per  second. 

punches  63.3 

Printer  speed 

Terminals 

CRT,  TTY 

Other 

Plotter,  communications,  analog  to  digital 

converters 

» 
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GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 
Data  General  NOVA  840  (continued) 


COMMENTS : 


Six  are  used  in  NORAD  Cheyenne  Mountain  Complex  Improvements 
in  the  central  system  and  four  are  used  as  interface 
processors. 


GENERALIZED  COMPUTER  EQU I PMENT  SPECIFICATIONS 


The  following  information  is  generalized  data  based  on  manufacturer's 
specifications.  This  equipment  is  used  in  the  ESD  system(s)  cited  in  the 
comments,  though  configuration  may  actually  vary. 


MANUFACTURER  &  MODEL  Data  General  NOVA  1220 


DATA  FORMAT 

Word  length  (bits) 

Fixed  point  operand  (bits) 
Instruction  length  (bits) 

Floating  point 

16 

16 

16 

MAIN  STORAGE 

Type 

Magnetic  core 

Cycle  time  (microseconds) 

1.2 

Capacity  (words) 

4K  to  32K 

Increments  (words) 

Interleaving 

Buffer  (cache)  storage 

Extended  memory 

CENTRAL  PROCESSOR 

CPU  configuration 

Registers 

4  accumulators;  2  index 

No.  directly  addressable  words 

1,024 

Indirect  addressing 

Multi-level 

Machine  cycle  time 

Instruction  time  (microseconds) 

Full  word  add  1.35 

Hardware  functional  units 

Standard:  byte  manipulation;  optional: 

multiply  and  divide,  floating  point 

Real-time  clock  or  timer 

Optional 

INPUT/OUTPUT  CONTROL 

I/O  word  size  (bits) 

16 

Maximum  I/O  rate  (words/second) 

833K 

No.  external  interrupt  levels 

16 

Number  I/O  channels 

PERIPHERAL  EQUIPMENT 

Disc  pack  storage 

Yes 

Non-interchangeable  disc  storage 

Yes 

Drum  storage 

No 

Magnetic  tape 

60K  characters  per  second 

Punched  card 

Up  to  1000  cards  per  minute  input 

Paper  tape 

400  characters  per  second  in  and  63.3  out 

Printer  speed 

Terminals 

CRT 

Other 

Plotters,  analog  to  digital  converters. 

i 

communications 

c 

A2-13 


5- 


'  t  - - - ~rr 


GENERALIZED  COMPUTER  EQUIPMENT  SPEC IFICATIONS 
Data  General  NOVA  1220  (continued) 


COMMENTS:  Forty  are  used  in  NORAD  Cheyenne  Mountain  Complex  Improvements 

as  display  processors  and  controllers. 
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GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 


The  following  information  is  generalized  data  based  on  manufacturer's 
specifications.  This  equipment  is  used  in  the  ESD  system(s)  cited  in  the 
comments,  though  configuration  may  actually  vary. 


MANUFACTURER  &  MODEL 


Digital  Equipment  Corporation  PDP  11/05 


DATA  FORMAT 

Word  length  (bits) 

Fixed  point  operand  (bits) 
Instruction  length  (bits) 

Floating  point 

16 

16 

16  or  32  or  48 

MAIN  STORAGE 

Type 

Magnetic  core 

Cycle  time  (microseconds) 

0.9  per  word 

Capacity  (words) 

4K  to  28K 

Increments  (words) 

Inter  leaving 

Buffer  (cache)  storage 

Extended  memory 

CENTRAL  PROCESSOR 

CPU  configuration 

Single  processor 

Registers 

8  accumulators,  8  index 

No.  directly  addressable  words 

32K  (28K  in  memory,  4K  in  I/O  semi- 

conductor  memories) 

Indirect  addressing 

One  level 

Machine  cycle  time 

Instruction  time  (microseconds) 

Full  word  add  3.7 

Hardware  functional  units 

Optional:  multiply,  divide;  standard: 

byte  manipulation,  literal  instructions 

Real-time  clock  or  timer 

Standard 

INPUT/OUTPUT  CONTROL 

I/O  word  size  (bits) 

16 

Maximum  I/O  rate  (words/second) 

2M 

No.  external  interrupt  levels 

Var iable 

Number  I/O  channels 

PERIPHERAL  EQUIPMENT 

Disc  pack  storage 

Yes 

Non-interchangeable  disc  storage 

Yes 

Drum  storage 

Special  order 

Magnetic  tape 

36K  maximum  characters  per  second 

Punched  card 

300  maximum  cards  per  minute  in,  75  out 

Paper  tape 

300  maximum  characters  per  second  in,  50 

out 

Printer  speed 

Terminals 

CRT 

Other 

Communications  interface 
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GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 
DEC  PDP  11/05  (continued) 

COMMENTS:  Used  in  COMBAT  GRANDE  system  for  call  processing  and  control 

within  the  PABX. 


GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 

The  following  information  is  generalized  data  based  on  manufacturer's 
specifications.  This  equipment  is  used  in  the  ESD  system(s)  cited  in  the 
comments,  though  configuration  may  actually  vary. 


MANUFACTURER  &  MODEL  Digital  Equipment  Corporation  PDP  11/10 

and  11/40 


DATA  FORMAT 

Word  length  (bits) 

Fixed  point  operand  (bits) 
Instruction  length  (bits) 

Floating  point 

16 

16 

16  or  32  or  48;  depends  on  addressing  and 
extensions 

MAIN  STORAGE 

Type 

Cycle  time  (microseconds) 
Capacity  (words) 

Increments  (words) 

Interleaving 

Buffer  (cache)  storage 

Extended  memory 

Magnetic  core 

900  microseconds  with  interleaving 

28K  words  (124K  words  for  11/40) 

Optional 

i 

CENTRAL  PROCESSOR 

CPU  configuration 

Registers 

No.  directly  addressable  words 
Indirect  addressing 

Machine  cycle  time 

Instruction  time  (microseconds) 

Hardware  functional  units 
Real-time  clock  or  timer 

Single  processor 

8  general  purpose;  2  of  which  are  program 
counter  and  hardware  stack 

64K  bytes 

4.6  add  from  memory,  7  memory  move  (2.38 
add,  3.2  move  for  11/40) 

INPUT/OUTPUT  CONTROL 

I/O  word  size  (bits) 

Maximum  I/O  rate  (words/second) 
No.  external  interrupt  levels 
Number  I/O  channels 

16 

2.5M 

Multilevel  priority  interrupt  system 

PERIPHERAL  EQUIPMENT 

Disc  pack  storage 

Non- inter changeable  disc  storage 
Drum  storage 

Magnetic  tape 

Punched  card 

Paper  tape 

Printer 

Terminals 

Other 

Yes 

Fixed  head 

No 

7  or  9  track,  or  cassette 

Yes 

Yes 

Yes 

CRT,  vector  graphics,  storage  tube 
analog  to  digital  converter 
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GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 
DEC  PDP  11/10  and  11/40  (continued) 


COMMENTS:  Used  in  COBRA  DANE  to  receive  post  mission  processing  output 

at  FTD  and  prepare  tape  for  input  to  UNIVAC  U-1180 


V 
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GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 


The  following  information  is  generalized  data  based  on  manufacturer's 
specifications.  This  equipment  is  used  in  the  ESD  system(s)  cited  in  the 
comments,  though  configuration  may  actually  vary. 


MANUFACTURER  &  MODEL 

Honeywell  H-716 

DATA  FORMAT 

Word  length  (bits) 

16 

Fixed  point  operand  (bits) 

16 

Instruction  length  (bits) 

16 

Floating  point 

MAIN  STORAGE 

Type 

Magnetic  core 

Cycle  time  (microseconds) 

0 . 755  per  word 

Capacity  (words) 

8K  to  65K 

Increments  (words) 

Interleaving 

Buffer  (cache)  storage 

Extended  memory 

CENTRAL  PROCESSOR 

CPU  configuration 

Single  processor 

Registers 

1  accumulator,  2  index 

No.  directly  addressable  words 

1,024 

Indirect  addressing 

Multi-level 

Machine  cycle  time 

Instruction  time  (microseconds) 

Full  word  add  1.55 

Hardware  functional  units 

Standard  multiply  and  divide  and  byte 

manipulation 

Real-time  clock  or  timer 

Standard 

INPUT/OUTPUT  CONTROL 

I/O  word  size  (bits) 

16 

Maximum  I/O  rate  (words/second) 

1M 

No.  external  interrupt  levels 

63 

Number  I/O  channels 

PERIPHERAL  EQUIPMENT 

Disc  pack  storage 

Yes 

Non-interchangeable  disc  storage 

Yes 

Drum  storage 

No 

Magnetic  tape 

112K  characters  per  second  maximum 

Punched  card 

Up  to  1050  cards  per  minute  in,  100  out 

Paper  tape 

Up  to  300  characters/second  in,  110  out 

Pr inter 

Up  to  6  printers 

Terminals 

Synchronous  and  asynchronous 

Other 

Cassette  tape,  graphics,  analog  to  digital 

and  communication  interfaces 

I 
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GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 
Honeywell  H-716  (continued) 


COMMENTS:  Two  Honeywell  H-716 's  are  used  in  the  NORAD  Cheyenne  Mountain 

Complex  Improvements  as  communication  processors  with  3 
Honeywell  Datanet  355  processors.  Also  used  in  WWMCCS  systems 
as  a  communications  controller  or  front  end  device. 
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GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 


The  following  information  is  generalized  data  based  on  manufacturer's 
specifications.  This  equipment  is  used  in  the  ESD  system(s)  cited  in  the 
comments,  though  configuration  may  actually  vary. 


MANUFACTURER  &  MODEL  Honeywell  H-6050  and  H-6060 


DATA  FORMAT 
Word  length  (bits.) 
Fixed  point  operand 
Instruction  length 

Floating  point _ 

MAIN  STORAGE 


(bits) 

(bits) 


36  (plus  parity) 

18  or  36  or  72 
36 

Single  or  double  word 


Type 

Cycle  time  (microsecond 
Capacity  (words) 
Increments  (words) 

Inter  leaving 

Buffer  (cache)  storage 

Extended  memory 


CENTRAL  PROCESSOR 


s) 


Magnetic  core 
1.2  (2  word  fetch) 
98K  to  524K 
Var ies 
2  way 


Bulk  storage  system,  1  to  3.5M  9  bit 
bytes,  6M  bytes  per  second  transfer  rate 


CPU  configuration 
Registers 


1  to  4  multiprocessor 

1  72  bit  AQ  accumulator,  8  18  bit  index, 
1  18  bit  base  address,  1  18  bit  instruc¬ 
tion  counter,  1  27  bit  timer,  1  8  bit 
exponent 


No.  directly  addressable  words 
Indirect  addressing 
Machine  cycle  time 
Instruction  time  (microseconds) 


Any  level  with  indexing  at  each  level 

Fixed  point  add  time  1.51;  typical  MIPS 
.5  to  .9  for  single  or  dual  processor 


Hardware  functional  units 

Real-time  clock  or  timer _ 

INPUT/OUTPUT  CONTROL 
I/O  word  size  (bits) 

Maximum  I/O  rate  (words/second) 
No.  external  interrupt  levels 

Number  I/O  channels _ 

PERIPHERAL  EQUIPMENT 
Disc  pack  storage 


Standard 


36 

1M 


Up  to  16  drives  per  controller,  each  drive 
up  to  133M  characters 


Non- in her changeable  disc 
Drum  storage 
Magnetic  tape 


storage 


Up  to  16  drives  per  controller,  up  to  160K 
characters  per  second  per  drive  (only  2 
can  operate  at  the  same  time) _ 


A2-21 


GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 


Honeywell  H-6050  and  H-6060  (contir.  1 ' 


PFRIPHERAL  EQUIPMENT  (continued) 

f 

Punched  card  i 

Up  to  1050  cards  per  minute  in,  400  cut 

Paper  tape 

500  characters  per  second  read,  150  punch 

Printer  speed 

Up  to  1200  lines  per  minute 

Terminals 

Synchronous  or  asynchronous 

Other 

!  Magnetic  character  reader,  optical 

[character  reader,  plotters 

COMMENTS:  The  H-6060  is  the  same  as  the  H-6050  except  that  it  offers  an 

Extended  Instruction  Set  of  over  100  new  instructions  that  can 
cut  time  and  memory  requirements  in  data  processing,  decimal 
arithmetic,  etc.  The  H-6050  was  the  original  WWMCCS  computer, 
but  has  been  replaced  by  H-60601  s,  mostly  in  a  2  CPU  multi¬ 
processor  configuration.  The  NORAD  Cheyenne  Mountain  Complex 
Improvements  has  H-6050  systems. 
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GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 

The  following  information  is  generalized  data  based  on  manufacturer's 
specifications.  This  equipment  is  used  in  the  ESD  system(s)  cited  in  the 
comments,  though  configuration  may  actually  vary. 


MANUFACTURER  &  MODEL  Honeywell  H-6C80 


DATA  FORMAT 

Word  length  (bits) 

36  (plus  parity) 

Fixed  point  operand  (bits) 

18  or  36  or  72 

Instruction  length  (bits) 

36 

Floating  point 

Single  or  double  word 

MAIN  STORAGE 

Type 

Magnetic  core 

Cycle  time  (microseconds) 

0.5  (2  word  fetch) 

Capacity  (words) 

131K  to  1M 

Increments  (words) 

Var ies 

Inter  leaving 

Buffer  (cache)  storage 

2  or  4  way 

Extended  memory 

Bulk  store  system;  1  to  3.5M  9  bit  bytes, 
10M  bytes  per  second  transfer  rate 

CENTRAL  PROCESSOR 

CPU  configuration 

1  to  4  multiprocessor 

Registers 

1  72  bit  AQ  accumulator,  8  18  bit  index, 

1  18  bit  base  address,  1  18  bit  instruc¬ 
tion  counter,  1  27  bit  timer,  1  18  bit 
exponent 

No.  directly  addressable  words 
Indirect  addressing 

Machine  cycle  time 

Any  level  with  indexing  at  each  level 

Instruction  time  (microseconds) 

Fixed  point  add  time  0.71;  typical  MIPS  1 
to  1.8  for  single  or  dual  processor 

Hardware  functional  units 
Real-time  clock  or  timer 

Standard 

INPUT/OUTPUT  CONTROL 

I/O  word  size  (bits) 

36 

Maximum  I/O  rate  (words/second) 
No.  external  interrupt  levels 
Number  I/O  channels 

1M 

PERIPHERAL  EQUIPMENT 

Disc  pack  storage 

Up  to  16  drives  per  controller,  each  drive 
up  to  133M  characters 

Non-interchangeable  disc  storage 
Drum  storage 

Magnetic  tape 

Up  to  16  drives  per  controller,  up  to  160R 
characters  per  second  per  drive,  (only  2 
can  operate  at  the  same  time) 
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GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 
Honeywell  H-6080  (continued) 


PERIPHERAL  EQUIPMENT  (continued) 

Punched  card 

Up  to  1050  cards  per  minute  in,  400  out 

Paper  tape 

500  characters  per  second  read,  150  punch 

Printer  speed 

Up  to  1200  lines  per  minute 

Terminals 

Synchronous  or  asynchronous 

Other 

Magnetic  or  optical  character  readers. 

plotters 

COMMENTS : 


The  H-6080  is  usually  in  dual  configuration  and  is  being 
introduced  into  the  WVJMCCS  system.  Three  H-6080 's  are  in  the 
NORAD  Cheyenne  Mountain  Complex  Improvements  system. 


GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 

The  following  information  is  generalized  data  based  on  manufacturer's 
specifications.  This  equipment  is  used  in  the  ESD  system(s)  cited  in  the 
comments,  though  configuration  may  actually  vary. 


MANUFACTURER  &  MODEL  IBM  370/155 


DATA  FORMAT 

Word  length  (bits) 

Fixed  point  operand  (bits) 
Instruction  length  (bits) 
Floating  point 

32  (4-8  bit  bytes) 

16  or  32  in  binary  mode 

2  or  4  or  6  bytes 

Standard  1  or  2  word 

MAIN  STORAGE 

Type 

Cycle  time  (microseconds) 
Capacity  (words) 

Increments  (words) 

Inter  leaving 

Buffer  (cache)  storage 

Extended  memory 

Magnetic  core,  virtual 

2.07  read  or  write  for  4  word  blocks 

66K  to  500K 

33K  to  131K 

No 

115  microseconds  for  2  bytes;  8K  bytes 
capacity 

CENTRAL  PROCESSOR 

CPU  configuration 

Registers 

No.  directly  addressable  words 
Indirect  addressing 

Machine  cycle  time 

Instruction  time  (microseconds) 

Hardware  functional  units 
Real-time  clock  or  timer 

Single  processor 

16  or  32  bit  for  index,  accumulator,  or 
base  address 

No 

115  microseconds 

Add  time:  0.99  microseconds  (32  bit 
binary  field),  4.93  microseconds  (5  digit 
decimal  field) 

Standard 

INPUT/OUTPUT  CONTROL 

I/O  word  size  (bits) 

Maximum  I/O  rate  (words/second) 
No.  external  interrupt  levels 
Number  I/O  channels 

5.4m  bytes  per  second 

2  to  5  block  multiplex,  1  or  2  byte 
multiplex 

PERIPHERAL  EQUIPMENT 

Disc  pack  storage 

Non-interchangeable  disc  storage 
Drum  storage 

Magnetic  tape 

Up  to  32  drives,  each  drive  up  to  200M 
bytes 

Each  drive  stores  up  to  11. 2M  bytes 

IBM  data  module  (trademark)  up  to  69. 8M 
bytes 

9  track,  up  to  6250  bits  per  inch,  up  to 
200  inches  per  second,  up  to  8  drives  per 
controller 
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GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 
IBM  370/150  (continued) 


PERIPERAL  EQUIPMENT  (continued) 

Punched  card 

Up  to  1000  cards  per  minute  in,  500  out 

Paper  tape 

Reads  up  to  100  characters  per  second 

Printer  speed 

Up  to  2500  lines  per  minute 

Terminals 

CRT,  graphic,  TTY,  sync/async 

Other 

Optical  or  magnetic  character  readers, 
programmable  communicat ion  processor 

COMMENTS:  One  system  used  in  AWACS  in  ground  support. 


GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 


The  following  information  is  generalized  data  based  on  manufacturer's 


specifications.  This  equipment  is  used  in  the  ESD  system(s)  cited  in  the 
comments,  though  configuration  may  actually  vary. 

MANUFACTURER  &  MODEL 

Intel  80 

DATA  FORMAT 

Word  length  (bits) 

8 

Fixed  point  operand  (bits) 

8  or  16 

Instruction  length  (bits) 

8  or  16  or  24 

Floating  point 

MAIN  STORAGE 

Type 

Semiconductor 

Cycle  time  (microseconds) 

2.0  per  word 

Capacity  (words) 

4K  to  16K 

Increments  (words) 

Inter  leaving 

Buffer  (cache)  storage 

Extended  memory 

CENTRAL  PROCESSOR 

CPU  conf iguration 

Single  processor 

Registers 

1  accumulator,  6  index 

No.  directly  addressable  words 

65K 

Indirect  addressing 

One  level 

Machine  cycle  time 

Instruction  time  (microseconds) 

Full  word  add  2.0 

Hardware  functional  units 

Byte  manipulation,  literal  instructions 

Real-time  clock  or  timer 

No 

INPUT/OUTPUT  CONTROL 

I/O  word  size  (bits) 

8 

Maximum  I/O  rate  (words/second) 

0.5M 

No.  external  interrupt  levels 

1 

Number  I/O  channels 

PERIPHERAL  EQUIPMENT 

Disc  pack  storage 

No 

Non-interchangeable  disc  storage 

No 

Drum  storage 

No 

Magnetic  tape 

Punched  card 

Paper  tape 

150  cards  per  second  input 

Printer  speed 

Terminals 

Other 

COMMENTS:  Used  in  COBRA  DANE  as  communications  controller. 
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GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 

The  following  information  is  generalized  data  based  on  manufacturer's 
specifications.  This  equipment  is  used  in  the  ESD  system(s)  cited  in  the 
comments,  though  conf iguration  may  actually  vary. 


MANUFACTURER  &  MODEL  Raytheon  RDS-500 


DATA  FORMAT 

Word  length  (bits) 

16 

Fixed  point  operand  (bits) 

16 

Instruction  length  (bits) 

16 

Floating  point 

Yes 

MAIN  STORAGE 

Type 

Magnetic  core 

Cycle  time  (microseconds) 

0.8  or  0.9  per  word 

Capacity  (words) 

8K  to  65K 

Increments  (words) 

Inter  leaving 

Buffer  (cache)  storage 

Extended  memory 

CENTRAL  PROCESSOR 

CPU  configuration 

Single  processor 

Reg isters 

8  general  purpose  accumulators,  8  index 

No.  directly  addressable  words 

65K 

Indirect  addressing 

No 

Machine  cycle  time 

Instruction  time  (microseconds) 

Full  word  add  1.6  or  1.8 

Hardware  functional  units 

Optional:  mult iply /divide,  float  point; 

standard:  byte  manipulation,  literal 

instructions 

Real-time  clock  or  timer 

Optional 

INPUT/OUTPUT  CONTROL 

I/O  word  size  (bits) 

16 

Maximum  I/O  rate  (words/second) 

2. 5M 

No.  external  interrupt  levels 

16 

Number  I/O  channels 

PERIPHERAL  EQUIPMENT 

Disc  pack  storage 

Yes 

Non-interchangeable  disc  storage 

Yes 

Drum  storage 

No 

Magnetic  tape 

30K  or  60K  or  120K  characters  per  second 

Punched  card 

300  or  1000  cards  per  second  in;  100  or 

400  out 

Paper  tape 

300  characters  per  second  in,  110  out 

Printer  speed 

Yes 

Terminals 

Array  processors,  plotters,  CRT's 

Other 

Communications 
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GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 
Raytheon  RDS- 500  (continued) 


COMMENTS : 


Used  in  COBRA  DANE  as  a  I/O  control  processor. 


GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 


The  following  information  is  generalized  data  based  on  manufacturer's 
specifications.  This  equipment  is  used  in  the  ESD  system(s)  cited  in  the 
comments,  though  configuration  may  actually  vary. 


MANUFACTURER  &  MODEL  ROLM  1603  (Ruggednova) 


DATA  FORMAT 

Word  length  (bits) 

Fixed  point  operand  (bits) 
Instruction  length  (bits) 

Floating  point 

16 

16 

16 

MAIN  STORAGE 

Type 

Magnetic  core  or  semiconductor 

Cycle  time  (microseconds) 

1.2  per  word 

Capacity  (words) 

Up  to  32K 

Increments  (words) 

256 

Inter leav ing 

Buffer  (cache)  storage 

Extended  memory 

CENTRAL  PROCESSOR 

CPU  configuration 

1  or  2  multiprocessor 

Registers 

4  accumulators,  2  index 

No.  directly  addressable  words 

1,024 

Indirect  addressing 

Multi-level 

Machine  cycle  time 

Instruction  time  (microseconds) 

Full  word  add  5.9 

Hardware  functional  units 

Optional:  multiply,  divide;  standard: 

byte  manipulation 

Real-time  clock  or  timer 

Optional 

INPUT/OUTPUT  CONTROL 

I/O  word  size  (bits) 

16  bits 

Maximum  I/O  rate  (words/second) 

285K 

No.  external  interrupt  levels 

16  to  256  levels 

Number  I/O  channels 

PERIPHERAL  EQUIPMENT 

Disc  pack  storage 

No 

Non-interchangeable  disc  storage 

Yes 

Drum  storage 

NO 

Magnetic  tape 

60K  characters  per  second  maximum 

Punched  card 

400  cards  per  minute  in 

Paper  tape 

300  characters  per  second  in,  63  out 

Printer  speed 

Terminals 

Yes 

Other 

Data  communications  interfaces,  analog  to 

digital  converter 

GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 
ROLM  1603  (Ruggednova)  (continued) 


COMMENTS: 


Used  in  dual  processor  mode  in  the  Air  Force 
Communications  System. 


Satellite 


f 
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GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 


The  following  information  is  generalized  data  based  on  manufacturer's 
specifications.  This  equipment  is  used  in  the  ESD  system(s)  cited  in  the 
comments,  though  configuration  may  actually  vary. 


MANUFACTURER  &  MODEL  Texas  Instruments  TI-980A 


DATA  FORMAT 

Word  length  (bits) 

Fixed  point  operand  (bits) 
Instruction  length  (bits) 

Floating  point 

16 

16 

16  or  32 

MAIN  STORAGE 

Type 

Semiconductor 

Cycle  time  (microseconds) 

0.75  per  word 

Capacity  (words) 

4K  to  65K 

Increments  (words) 

Interleaving 

Buffer  (cache)  storage 

Extended  memory 

CENTRAL  PROCESSOR 

CPU  configuration 

Registers 

2  accumulators,  1  index 

No.  directly  addressable  words 

65K 

Indirect  addressing 

One-level 

Machine  cycle  time 

Instruction  time  (microseconds) 

Full  word  add  1.75 

Hardware  functional  units 

Standard:  multiply  and  divide,  byte 

manipulation,  literal  instructions 

Real-time  clock  or  timer 

Optional 

INPUT/OUTPUT  CONTROL 

I/O  word  size  (bits) 

16 

Maximum  I/O  rate  (words/second) 

1.3M 

No.  external  interrupt  levels 

2-64 

Number  I/O  channels 

PERIPHERAL  EQUIPMENT 

Disc  pack  storage 

Yes 

Non-interchangeable  disc  storage 

Yes 

Drum  storage 

NO 

Magnetic  tape 

300K  characters  per  second  maximum  speed 

Punched  card 

300  cards  per  minute  in;  100  out 

Paper  tape 

300  characters  per  second  in;  60  out 

Printer  speed 

Terminals 

Yes 

Other 

Analog  to  digital  converter,  communica- 

tions  interfaces 

GENER  II  ZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 


COMMENTS : 


Texas  Instruments  TI-980A  (continued) 


In  COMBAT  GRANDE,  28  of  these  systems  were  used  as  display 
console  controllers,  2  as  primary  and  backup  display  system 
controllers  and  7  at  the  individual  long  range  radar  sites  as 
a  data  extractor  controller. 


GENERALISED  COMPUTER  EQUIPMENT  SPECIFICATIONS 


The  foil  owing  information  is  generalized  data  based  on  nan. fast  ..  • '  * 

spec  if  icat :  ar.s.  This  equipment  is  used  in  the  ESD  system  (3:  sited  ;r.  “he 

0  s.TJiierC  3 ,  t.nough  configuration  may  actually  vary. 

MANUFACTURER  &  MODEL 

UN I VAC  AN/UYK-7 

DATA  FORMAT 

Word  length  (bits) 

32 

Fixed  point  operand  (bits) 

8,  16,  32,  or  64 

Instruction  length  (bits) 

16  or  32 

Floating  point 

8,  16,  32,  or  64 

MAIN  STORAGE 

Type 

Magnetic  core  (or  thin  film) 

Cycle  time  (microseconds) 

1.5  (down  to  0.75  effective  rate  for  over- 

Capacity  (words) 

lapping  requests  to  thin  film) 

3  increments  internally,  up  to  13  external 

Increments  (words) 

increments  of  shared  memory. 

16K  ( 32K) 

Inter  leaving 

2  level  (optional) 

Buffer  (cache)  storage 

No 

Extended  memory 

No 

CENTRAL  PROCESSOR 

CPU  configuration 

1  to  3  CPU  multiprocessors 

Registers 

2  sets  of  19  bit-  index,  8-32  bit  accumu- 

No.  directly  addressable  words 
Indirect  addressing 

lators,  2  sets  of  8  -  18  bit  base  (addres- 
able  only  in  interrupt  mode) ,1-23  bit 
status,  1-18  bit  breakpoint,  1-20  bit 
address,  82  integrated  circuit  registers 
used  for  CPU  control  memory 

One  level 

Machine  cycle  time 

Instruction  time  (microseconds) 

Add  1.5  (1.2),  multiply  7.5  (7.5),  divide 

Hardware  functional  units 

14.5  ,14.5) ,  shift  1.75  (1.75) 

None 

Real-time  clock  or  timer 

Standard 

INPUT/OUTPUT  CONTROL 

I/O  word  size  (bits) 

32  bit  parallel  (or  optional  bit  serial) 

Maximum  I/O  rate  (words/second) 

167K  per  channel 

No.  external  interrupt  levels 

28  types  of  interrupts  in  4  levels 

Number  I/O  channels 

Up  to  16,  all  computer  to  computer  capable 

PERIPHERAL  EQUIPMENT 

Disc  pack  storage 

8,  16,  or  32M  bit  per  handler,  17 

Non-interchangeable  disc  storage 

millisecond  access 

No 

Drum  storage 

No 

p 


GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 
UNIVAC  AN/UYK-7  (continued) 
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PERIPHERAL  EQUIPMENT  (continued) 

Magnetic  tape 

7  or  9  track,  800  or  1600  bits  per  inch, 

120  inches  per  second 

Punched  card 

Read  600  cards  per  minute,  punch  75 

Paper  tape 

Read  300  characters  per  second,  punch  75 

Printer  speed 

132  characters  per  line,  400  lines  per 
minute 

Terminals 

Synchronous  or  asynchronous 

Other 

Navy  Tactical  Data  System  (NTDS)  interface 
North  Atlantic  Treaty  Organization  (NATO) 
standard  interface  (development) . 

All  the  above  peripherals  are  militarized 
or  ruggedized;  higher  speed  commercial 
peripherals  are  available  for  use  in  a 
non-hostile  environment. 

COMMENTS:  Used  in  TACSI  as  data  processing  and  display  computers. 
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GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 

The  following  information  is  generalized  data  based  on  manufacturer's 
specif ications.  This  equipment  is  used  in  the  ESD  system(s)  cited  in  the 
comments,  though  configuration  may  actually  vary. 


MANUFACTURER  &  MODEL 


UNIVAC  AN/UYK  20  (U-1600) 


DATA  FORMAT 
Word  length  (bits) 

Fixed  point  operand  (bits) 
Instruction  length  (bits) 

Floating  point _ 

MAIN  STORAGE 
Type 

Cycle  time  (microseconds) 
Capacity  (words) 

Increments  (words) 

Inter leav ing 

Buffer  (cache)  storage 

Extended  memory _ 

CENTRAL  PROCESSOR 
CPU  configuration 
Registers 

No.  directly  addressable  words 
Indirect  addressing 
Machine  cycle  time 
Instruction  time  (microseconds) 

Hardware  functional  units 


16 

16 

16  or  32  bit 

Yes _ 

Magnetic  core 

0.75  read  and  restore 

32K  (512K  with  new  memory  system) 

8K  (32K  with  new  memory  system) 


Real-time  clock  or  timer _ 

INPUT/OUTPU-  CONTROL 
I/O  word  size  (bits) 

Maximum  I/O  rate  (words/second) 
No.  external  interrupt  levels 

Number  I/O  channels _ 

PERIPHERAL  EQUIPMENT 
Disc  pack  storage 
Non-interchangeable  disc  storage 
Drum  storage 
Magnetic  tape 


4  page  address,  16  or  32  high-speed 
general  purpose,  2  program  status 
65K 

One'  Ye're  1 

Add  .84,  shift  1.0,  multiply  3.6,  divide 
6.6 

Microprogrammed  controller.  Math  Pack: 
microprogrammed  ROM  square  root,  trigono¬ 
metric  and  hyperbolic  functions,  floating 
point,  double  precision  multiply  or 
divide,  512  words  of  user  defined  micro- 
jmemory 

Standard _ 

Variable  up  to  16  bit 
1M  (combined  rate) 

3  level 

16  combined  serial  and  parrallel _ 

8,  16,  or  32M  bit,  17  millisecond  access 

No 

No 

7  or  9  track,  800  or  1600  bits  per  inch, 
120  inches  per  second 
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GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 


UN I VAC  AN/UYK  —  20  (U-1600)  (continued) 


PERIPHERAL  EQUIPMENT  (continued) 

Punched  card 

Read  600  cards  per  minut°,  punch  75 

Paper  tape 

Read  300  characters  per  second,  punch  73 

Printer  speed 

132  characters  per  line,  400  lines  per 
minute 

Terminals 

Synchronous  to  9600  bits  per  second,  1 

asynchronous  to  2400  bits  per  second 

Other 

Navy  Tactical  Data  System  (NTDS) 
interface,  VACATES  (USMC  tactical  data 
system)  interface.  North  Atlantic  Treaty 

Organization  (NATO)  standard  interface 
(development.  ) 

All  of  the  above  peripherals  are 

militarized  or  ruggedized;  higher  speed 
commercial  peripherals  are  available  for 
use  in  a  non-hostile  environment. 

COMMENTS:  U-1600  is  the  Air  Force  designation  for  this  compute:. 

2  U-1600 's  are  used  in  CONUS  Over-the-Hor izon  Backscatter 

Radar;  Combat  Theater  Communications  uses  1  as  a  central 
processor.  The  ANAJYK-20  is  used  in  the  Joint  Tactical 
Information  Distribution  System  as  a  translator  processor. 


i 
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GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 


The  following  information  is  generalized  data  based  on  manufacturer's 
specifications.  This  equipment  is  used  in  the  ESD  system(s)  cited  in  the 
comments,  though  configuration  may  actually  vary. 


MANUFACTURER  &  MODEL  UNIVAC  U-1108 


DATA  FORMAT 

Word  length  (bits) 

36 

Fixed  point  operand  (bits) 

12  or  18  or  36  or  72 

Instruction  length  (bits) 

36 

Floating  point 

Yes 

MAIN  STORAGE 

Type 

Magnetic  core 

Cycle  time  (microseconds) 

0.75 

Capacity  (words) 

65K  to  262K 

Increments  (words) 

65K 

Inter  leaving 

Buffer  (cache)  storage 

Standard 

Extended  memory 

No 

CENTRAL  PROCESSOR 

CPU  configuration 

1  to  3 

Reg  isters 

128  125  nanosecond  integrated  circuit 
control  registers,  15  index,  16  accumu¬ 
lators,  8  unassigned,  1  each:  repeat 
count,  mask  processor  state 

No.  directly  addressable  words 

16M  words  with  register  extended 
addressing 

Indirect  addressing 

Any  desired  level 

Machine  cycle  time 

Register  time  125  microseconds 

Instruction  time  (microseconds) 

Fixed  add  0.75,  long  add  1.63,  fixed 
multiply  2.38,  fixed  divide  10.13,  store 
0.75 

Hardware  functional  units 
Real-time  clock  or  timer 

Yes 

INPUT/OUTPUT  CONTROL 

I/O  word  size  (bits) 

36 

Maximum  I/O  rate  (words/second) 
No.  external  interrupt  levels 
Number  I/O  channels 

Up  to  16,  each  channel  can  handle  up  to  16 
devices 

PERIPHERAL  EQUIPMENT 

Disc  pack  storage 

Up  to  8  drives  per  controller,  26M  words 
per  dr ive 

Non-interchangeable  disc  storage 

Up  to  366M  words 

Drum  storage 

Up  to  8  drums  per  controller,  up  to  33M 
words  per  drum 

GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 


UNIVAC  U-1108  (continued) 


PERIPHERAL  EQUIPMENT  (continued) 

Magnetic  tape 

7  or  9  track,  up  to  200  inches  per  second. 

up  to  1600  bits  per  inch,  up  to  16 

handlers  per  system 

Punched  card 

Up  to  1000  cards  per  minute  in,  300  out 

Paper  tape 

Printer  speed 

Up  to  1600  lines  per  minute 

Term inals 

TTY,  CRT,  synchronous/asi  chronous 

Other 

COMMENTS:  Used  in  COBRA  DANE  at  the  FTD  for  post  mission  analysis. 
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GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 


The  following  information  is  generalized  data  based  on  manufacturer's 
specifications.  This  equipment  is  used  in  the  ESD  system(s)  cited  in  the 
comments,  though  configuration  may  actually  vary. 


MANUFACTURER  &  MODEL  UNIVAC  U-1110 


DATA  FORMAT 

Word  length  (bits) 

36 

Fixed  point  operand  (bits) 

12  or  18  or  36  or  72 

Instruction  length  (bits) 

36 

Floating  point 

Yes 

MAIN  STORAGE 

Type 

Plated  wire 

Cycle  time  (microseconds) 

Read  0.32,  write  0.52 

Capacity  (words) 

32K  to  262K 

Increments  (words) 

32K 

Inter  leaving 

Buffer  (cache)  storage 

Standard 

Extended  memory 

Magnetic  core,  131K  to  1M,  0.75  or  1.5 
microsecond  cycle  time,  optional 
interleaving 

CENTRAL  PROCESSOR 

CPU  configuration 

1  to  4  multiprocessor 

Registers 

112  75  nanosecond  integrated  circuit 
control  registers,  15  index,  16  accumu¬ 
lator,  1  each:  repeat,  mask,  real-time 
clock,  several  unassigned  fast-access 
temporary  storage. 

No.  directly  addressable  words 

262K  (4  processor)  and  1048K  of  extended 
stores 

Indirect  addressing 

Any  desired  level 

Machine  cycle  time 

Register  time  75  nanoseconds 

Instruction  time  (microseconds) 

Fixed  add  0.3,  fixed  multiply  1.5,  fixed 
divide  6.4,  store  0.3 

Hardware  functional  units 
Real-time  clock  or  timer 

Yes 

INPUT/OUTPUT  CONTROL 

I/O  word  size  (bits) 

36 

Maximum  I/O  rate  (wc -ds/second) 
No.  external  interrupt  levels 

4M 

Number  I/O  channels 

—  J 

Up  to  24,  each  channel  can  handle  up  to  16 
devices 

iwiyy 
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GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 
UNIVAC  U-1I10  (continued) 


PERIPHERAL  EQUIPMENT  (continued) 
Disc  pack  storage 

Non-inter  changeable  disc  storage 
Drum  storage 

Magnetic  tape 


Punched  card 
Paper  tape 
Printer  speed 
Terminals 
Other _ _ 

COMMENTS:  Has  a  4  deep  instruction  stack  for  lookahead  and  concurrency. 

One  of  these  systems  was  used  in  CONUS  Over-the-Hor izon 
Backscatter  Radar. 


26M  words  per  drive,  up  to  8  drives  per 

controller 

Up  to  366M  words 

Up  to  8  drums  per  controller,  up  to  33M 
words  per  drum 

7  or  9  track,  up  to  200  inches  per  second, 
up  to  1600  bits  per  inch,  up  to  16 
handlers  per  system 

Up  to  1000  cards  per  minute  in,  300  out 

Up  to  1600  lines  per  minute 

TTY,  CRT,  synchronous/asynchronous 
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GENERALIZED  COMPUTER  EQUIPMENT  SPECIFICATIONS 


The  +ollowing  information  is  generalized  data  based  on  manufacturer's 
specifications.  This  equipment  is  used  in  the  ESD  system ;  r.)  cited  ip.  the 
romments,  though  configuration  may  actually  vary. 


MANUFACTURER  &  MODEL 


UN I VAC  U-1616 


DATA  FORMAT 

Word  length  (bits) 

Fixed  point  operand  (bits) 
Instruction  length  (bits) 

Floating  point 

16+2  (parity) 

8  or  16  or  32 

16  or  32 

MAIN  STORAGE 

Type 

Magnetic  core 

Cycle  time  (microseconds) 

0.75 

Capacity  (words) 

8K  to  65K 

Increments  (wc  is) 

Inter  leaving 

Buffer  (cache)  storage 

Extended  memory 

CENTRAL  PROCESSOR 

CPU  configuration 

Single  processor 

Reg  isters 

16  to  64  accumulators 

No.  directly  addressable  words 

65K 

Indirect  addressing 

One  level 

Machine  cycle  time 

Instruction  time  (microseconds) 

Full  word  add  1.0 

Hardware  functional  units 

Optional:  multiply  and  divide;  standard: 

byte  manipulation,  literal  instructions 

Real-time  clock  or  timer 

Optional 

INPUT/OUTPUT  CONTROL 

I/O  word  size  (bits) 

8  or  16  or  32 

Maximum  I/O  rate  (words/second) 

1.3M 

No.  external  interrupt  levels 

8 

Number  I/O  channels 

PERIPHERAL  EQUIPMENT 

Disc  pack  storage 

Yes 

Non-interchangeable  disc  storage 

Yes 

Drum  storage 

No 

Magnetic  tape 

200K  characters  per  second  maximum  speed 

Punched  card 

200  cards  per  minute  in;  75  out 

Paper  tape 

200  characters  per  second  in;  75  out 

Printer  speed 

Terminals 

TTY,  CRT 

Other 

COMMENTS:  Two  of  these  systems  were  used  in  CONUS  OTH-B. 


A2-43 


**$■**? 


TAB  B  SIZING  AND  TIMING  PARAMETERS 


1.0  INTRODUCTION 

This  Tab  contains  eleven  sets  of  sizing  and  timing  relationships  that 
have  been  developed  through  analytical  techniques  (also  see  Analytical 
Techniques  in  Tab  A  of  Volume  I  of  this  handbook)  .  The  graphics  are 
presented  to  illustrate  the  types  of  relationships  that  can  be  developed 
by  analytical  techniques  and  to  demonstrate  the  relative  trends  in 
computer  system  sizing  and  timing  parameters.  Although  these  graphs  were 
created  specifically  for  this  handbook,  the  algorithms  upon  which  many 
were  based  were  developed  during  the  past  several  years.  In  addition, 
some  of  the  algorithms  were  derived  through  analysis  of  data  that  dated 
back  to  1969.  One  must  acknowledge  that  during  the  past  decade  there  has 
been  considerable  advancement  in  computer  science  technology  that  would 
impact  on  the  sizing  and  timing  relationships  illustrated,  such  as  the 
increased  speed  and  density  of  storage,  and  the  advent  of  modern 
programming  techniques.  Accordingly,  users  of  this  handbook  are  cautioned 
not  to  consider  the  relationships  illustrated  in  this  tab  as  anything  more 
than  additional  possible  data  points  that  might  be  considered  in  the 
overall  evaluation  of  a  computer  system's  sizing  and  timing  parameters. 
It  is  suggested  that  the  relationships  illustrated,  as  well  as  many 
others,  could  be  made  viable  by  the  engineers  and  computer  scientists  of 
ESD/TOI  through  data  collection  and  analyses  of  sizing  and  timing 
parameters  pertaining  to  recently  completed  or  current  ESD  projects. 

1.1  Derivation  of  Relationships. 

The  derivations  of  relationships  presented  in  this  Tab  are  discussed 
in  the  following  sections  and  Tab  B  introductory  pages. 


1.1.1  Tabs  B.l.  through  B.5  (pages  B-7  through  B-40).  These 
relationships,  regarding  memory  size  and  cycle  times,  were  derived  from  an 
algorithm  developed  by  Doty  Associates  3/  in  1977  and  are  based  on  the 
analysis  of  data  obtained  from  a  study  sponsored  by  the  Office  of  the 
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Secretary  of  Defense,  and  performed  by  the  Johns  Hopkins  University 
Applied  Physics  Laboratory  4/.  Although  the  data  contained  def iciencies, 
the  following  algorithm  was  developed  using  multivariate  regression: 


M 


«°-337w0'147 

F _ S _ 

0.770 


0.177+k 

e 


where 


(Equation  1) 


NOTE: 


M  =  Memory  size  in  thousands  of  words  of  object  code 

Np  =  Number  of  major  functions  to  be  performed  by  the 
software. 

Ws  =  Word  size  in  bits 

tc  =  Cycle  time  of  processor  in  microseconds 

k  =  A  constant  dependent  on  application 
where  k  equals: 

2.573  for  signal  processing 
2.727  for  missile  fire  control 
2.781  for  interfacing 
3.412  for  communication 
3.565  for  navigation 
4.046  for  command  and  control 
4.451  for  weapon  fire  control 

R2  =  0.52 

R2  is  the  coefficient  of  determination  and  is  a  measure  of 
hew  well  the  data  points  fit  the  curve,  with  the  better  the 
fit  the  closer  R2  is  to  a  value  of  1.0. 


Perhaps  the  variable  Np,  major  function,  is  best  defined  by 
examples,  such  as;  communications,  target  tracking,  target  identification, 
navigation,  system  monitoring,  display,  steering,  parameter  measurement, 
tuning,  target  data  entry,  firing  sequence  control,  etc.  This  would 
include  operating  system  functions.  Wg  and  t  are  essentially 
dictated  by  the  CPU  in  the  computer  system.  Based  on  the  type  of 
application,  most  of  which  are  in  real-time,  few  overlays  would  be 
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expected.  If  the  core  utilization  is  assumed  to  be  approximately  80 
percent,  the  algorithm  could  be  considered  for  estimating  software  size. 

By  varying  different  aspects  of  the  algorithm,  various  relationships 
were  developed. 

1.1.2  Tab  B.6  (pages  B-41  through  B-44).  This  set  of  relationships  is 
based  on  queuing  theory.  The  curves  illustrate  the  relationships  among 
the  number  of  Input/Output  (I/O)  terminals,  the  probable  response  time 
depending  on  the  CPU  service  time,  and  the  interval  between  terminal 
messages. 

1.1.3  Tab  B.7  (pages  B-45  through  B-47).  This  set  of  curves  illustrates 
the  relationship  between  the  number  of  lines  of  source  instructions  to  be 
developed  and  the  number  of  months  required  to  develop  them.  The  curves 
are  based  on  two  research  efforts  conducted  by  Walston  5/  and  Graver  2/  in 
1977.  Walston  developed  the  following  algorithm: 


M  =  4.1  J^I 0  -  3  6  J 


(Equation  2) 


Where 


M  =  Months  of  effort  required  to  develop  software. 

I  =  Total  number  of  delivered  lines  of  source 

code  (excluding  comments)  in  thousands. 

Graver  developed  a  number  of  algorithms  as  part  of  an  initial  software 
costing  model,  one  of  which  included  a  multiplier  based  on  core 
utilization: 


Fu  =  1-V 


Where 


(Equation  3) 


=  Multiplier  based  on  core  utilization. 
P  =  Percent  of  core  utilized. 


( 
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From  the  above  equation,  DAI  derived: 


t  n  28 

F  =  F  (Equation  4) 

u  u 

Where 

I 

F  =  A  factor  for  core  utilization 
u 

Equation  4  was  then  combined  with  Equation  2  to  produce  Equation  5  and 
the  relationships  illustrated  in  Tab  B  regarding  the  impact  of  core 
utilization  on  months  of  development  time: 


M  =  4.1Fu  ^  j0  *  36 J  (Equation  5) 

Use  of  the  above  algorithm  (Equation  5)  demonstrates  that  increased  core 
utilization  does  impact  on  development  time,  however,  it  does  not  appear 
to  demonstrate  that  as  core  utilization  approaches  100  percent  the 
development  time  should  increase  exponentially  due  to  both  core  constraint 
and  size  of  the  developmental  software  package.  It  is  hypothesized  that  a 
more  accurate  algorithm  would  be  as  follows: 

M-4.1Fy  [i0*36  +  k^(P)J  (Equation  6) 

However,  the  exponent,  kf(P)  needs  to  be  defined. 


1.1.4  Tab  b.8  (pages  B-48  through  B-50) .  The  manmonths  of  software 
development  time  vs  core  utilizations  relationships  in  Tabs  B.8.1  and 
B.8. 2  were  developed  by  combining  another  algorithm  by  Doty  Associates 

I 

with  Fy  cited  in  Equation  4  above: 

MM  =  4. 089F^  ^I1*26^  (Equation  7) 

Where 

MM  =  Manmonths  of  effort  required  to  develop  software. 

I  =  Total  number  of  delivered  lines  of  source  code 
(excluding  comments)  in  thousands. 


1.1.5  Tabs  B.9  through  B.ll  (pages  B-51  through  B-58).  These  relative 
relationships  involving  fast  storage  capacity  requirements,  air  targets 
tracked,  and  air  target  speeds  were  based  on  the  application  of  algorithms 
developed  by  Frederic  1/  in  1974,  that  are  presented  below: 


A.  For  fighter  targets 

Sf  =  14.30T1'05  (Equation  8) 

Where 

Sf  =  Total  words  (in  thousands)  in  fast  storage 
(storage  units  with  retrieval  rates  in  the 
order  of  a  thousand  times  faster  than  slower 
storage  such  as  random  access  vice  sequential 
access) . 

T  =  number  of  targets  being  tracked. 

B.  For  helicopter  targets 

Sf  =  8.30T1-05  (Equation  9) 

C.  For  fighter  targets 

0^  =  14t1-51  (Equation  10) 

Where 

0^  =  Total  operating  instructions  (in  thousands). 


D.  For  helicopter  targets 

0i  =  iot1-51 


(Equation  11) 
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TAB  B.l  APPLICATIONS  VS.  CYCLE  TIME 


The  relationships,  illustrated  in  this  set  of  Tabs,  B.1.1  through  B-1.6, 
were  developed  through  the  application  of  the  algorithm  (Equation  1} 
discussed  in  Tab  B,  Section  1.1.1.  These  curves  illustrate  the 
relationship  between  CPU  cycle  time,  major  system  applications,  word  size 
and  total  words  of  object  code,  not  necessarily  core  resident.  The 
general  relationship  is  that  the  faster  the  CPU,  the  larger  the  size  of 
software  in  object  words.  The  effect  becomes  dramatic  for  CPUs  with  cycle 
time  less  than  1.5  microseconds. 


APPLICATIONS  VS.  CYCLE  TIME 


Tab  Page 


B.1.1  8  bits/word  size . B-  8 

B.l.  2  12  bits/word  size . B-  9 

B.1.3  16  bits/word  size . B-10 

B.l. 4  24  bits/word  size . B-ll 

B.l. 5  32  bits/word  size . B-12 

B.l. 6  64  bits/word  size  .........  B-13 
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APPLICATIONS 


B  B.1.3  APPLICATION  VS  CYCLE  TIME 
(16  BITS/WORD  SIZE) 


COMMAND  AND  CONTROL 

COMMUNICATION 

INTERFACING 

MISSILE  FIRE  CONTROL 


B-ll 


COMMAND  AND  CONTROL 


TAB  B.1.5  APPLICATION  VS  CYCLE  TIME 
(32  BITS/WORD  SIZE) 


APPLICATIONS 

800  '  G\  A  -  COMMAND  AND  CONTROL 

\  B  -  COMMUNICATION 

\  C  -  INTERFACING 
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TAB  B. 2 


OBJECT  WORDS  VS.  THE  NUMBER  OF  MAJOR  FUNCTIONS 


The  relationships,  illustrated  in  this  set  of  Tabs,  B.2.1  through  R.2.7, 
were  developed  through  the  application  of  the  algorithm  (Equation  1) 
discursed  in  Tab  B,  Section  1.1.1.  These  curves  relate  initial  estimates 
of  total  object  words  to  the  number  of  major  functions  within  a  system 
application.  In  addition,  word  size  and  CPU  cycle  time  are  displayed. 
Major  functions  in  this  context  are  considered  primary  actions  that  must 
be  executed  by  the  software  to  accomplish  its  c3  mission  requirements, 
such  as  target  tracking,  target  identification,  navigation,  etc. 


OBJECT  WORDS  VS.  THE  NUMBER  OF  MAJOR  FUNCTIONS 
(1.0  micro-second  cycle  time) 


Tab  Page 


B.2.1  COMMAND  AND  CONTROL . B-15 

B.2.2  COMMUNICATION . B-16 

B.2.3  INTERFACING . B-17 

B.2.4  MISSILE  FIRE  CONTROL . B-18 

B.2.5  NAVIGATION . B-19 

B.2.6  SIGNAL  PROCESSING  .  B-20 

B.  2.7  WEAPON  FIRE  CONTROL . B-21 
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TAB  B.2.3  OBJECT  WORDS  VS  THE  NUMBER  OF  MAJOR  FUNCTIONS 

(INTERFACING) 


BITS/WORD 


B-20 


OBJECT  WORDS  VS  THE  NUMBER  OF  MAJOR  FUNCTIONS 
(SIGNAL  PROCESSING) 


TAB  B.3  WORD  SIZE  VS.  CYCLE  TIME 


The  relationships  illustrated  in  this  Tab,  B.3.1,  were  developed  through 
the  application  of  the  algorithm  (Equation  1)  discussed  in  Tab  B,  Section 
1.1.1.  These  curves  illustrate  the  relationships  among  word  size,  total 
object  words  and  CPU  cycle  time  for  a  combincition  of  ten  major  software 
functions.  It  illustrates  the  insensitivity  of  the  effect  of  increasing 
word  size  on  total  object  code. 


Tab  Page 

B.3.1  WORD  SIZE  VS.  CYCLE  TIME . B-23 
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CYCLE  TIME  (IN  MICROSECONDS) 


TAB  B . 4  MEMORY  SIZE  VS.  NUMBER  OF  FUNCTIONS 


The  relationships  illustrated  in  this  set  of  Tabs,  B.4.1  through  B.4.9, 
were  developed  through  the  application  of  the  algorithm  (Equation  1) 
discussed  in  Tab  B,  Section  1.1.1.  These  curves  relate  major  functions, 
word  size  and  memory  size  for  different  cycle  times.  The  general 
relationship  is  that  as  the  number  of  major  functions  increases,  the 
memory  size  required  increases  and  that  larger  word  sizes  result  in  the 
use  of  more  memory.  Curves  span  several  CPU  cycle  times,  frot  4.0  to  0.25 
microseconds.  Note  that  as  cycle  time  decreases,  the  requirement  for 
memory  size  increases. 


MEMORY  SIZE  VS.  NUMBER  OF  FUNCTIONS 
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TAB  B.4.4  MEMORY  SIZE  VS  NUMBER  OF  FUNCTIONS 
(1.75  MICROSECONDS  CYCLE  TIME) 
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TAB  B.4.5.  MEMORY  SIZE  VS  NUMBER  OF  FUNCTIONS 
(1.5  MICROSECONDS  CYCLE  TIME) 
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B-  30 


CAUTION 


MEMORY  SIZE  VS  NUMBER  OF  FUNCTIONS 
(1.0  MICROSECONDS  CYCLE  TIME) 


THESE  RELATIONSHIPS  ARE 


TAB  B.4.8  MEMORY  SIZE  VS  NUMBER  OF  FUNCTIONS 
10.5  MICROSECONDS  CYCLE  TIME) 


B-33 


TAB  B. 5  MEMORY  SIZE  VS.  CYCLE  TIME  AND 
NUMBER  OF  FUNCTIONS 


The  relationships  illustrated  in  this  set  of  Tabs,  B.5.I  through  B. 3.6, 
were  developed  through  the  application  of  the  algorithm  (Equation  1} 
discussed  in  Tab  B,  Section  1.1.1.  These  curves  illustrate  the 
relationships  among  memory  size  and  major  functions  for  various  cycle 
times  and  memory  word  sizes.  Given  the  cycle  time  and  number  of  major 
functions,  an  estimate  of  memory  size  is  given.  As  cycle  time  decreases 
the  memory  size  requirement  inc.  eases.  As  one  progresses  from  8  to  64 
bits/word  on  the  graphs,  the  demand  for  memory  size  also  increases.  The 
word  sizes  include  8,  12,  16,  24,  32,  and  64  bits/word. 


MEMORY  SIZE  VS.  CYCLE  TIME  AND 
NUMBER  OF  FUNCTIONS 
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B.5.1  8  bits/word . B-35 

B.5.2  12  bits/word . B-36 

B.5.3  16  bits/word . B-37 

B.5.4  24  bits/word . B-38 

B.5.5  32  bits/word . B-39 

B.5.6  64  bits/word . B-40 
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TAB  B.5.2  MEMORY  SIZE  VS  CYCLE  TIME  AND  NUMBER  OF  FUNCTIONS 

(12  BITS/WORD) 


HI  l  A  HONSHU'S  AH 


MEMORY  SIZE  VS  CYCLE  TIME  AND  NUMBER  OF  FUNCTIONS 
(16  BITS/WORD) 
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TAB  B.6  MESSAGE  RESPONSE  TIME  VS.  NUMBER  OF 
INPUT/OUTPUT  (I/O)  TERMINALS 


The  relationships  illustrated  in  this  set  of  Tabs,  B.6.1  through  B.6. 3, 
were  developed  through  the  application  of  queuing  theory.  These  curves 
illustrate  the  relationships  among  the  number  of  I/O  terminals,  the 
probable  response  time  depending  on  CPU  service  time,  and  the  interval 
between  terminal  messages.  It  should  be  noted  that  as  the  service  time 
becomes  less,  the  easier  it  is  to  service  more  terminals.  The  curves  also 
show  that  the  longer  the  time  between  terminal  messages,  the  easier  it  is 
to  accommodate  more  terminals.  The  limiting  factor  is  approximated  by 
dividing  the  interval  between  terminal  messages  by  the  service  time  to  get 
the  limiting  number  of  I/O  terminals  that  can  reasonably  be  serviced. 


MESSAGE  RESPONSE  TIME  VS.  NUMBER 
OF  INPUT/OUTPUT  (I/O)  TERMINALS 


Tab  Page 

B.6.1  2.0  seconds  service  time . B-42 

B.6. 2  1.0  second  service  time . B-43 

B.6. 3  0.5  second  service  time . B-44 
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TAB  B.7  MONTHS  OF  SOFTWARE  DEVELOPMENT  TIME  VS. 
CORE  UTILIZATION 


The  relationships  illustrated  in  this  set  of  Tabs,  B.7.1  and  B.7. 2,  were 
developed  through  the  application  of  the  algorithm  (Equation  5)  discussed 
in  Tab  B,  Section  1.1.3.  These  curves  illustrate  the  relationship  between 
the  number  of  lines  of  source  instructions  that  are  to  be  developed,  and 
the  number  of  months  required  to  develop  them,  considering  the  impact  of 
core  utilization.  The  use  of  the  algorithm  (Equation  5)  indicates  that 
the  development  time  increases  as  the  core  utilization  increases  (see  Tabs 
B.7.1  and  B.7. 2).  in  reality,  the  increase  in  the  development  time  should 
increase  more  exponentially  as  illustrated  by  the  suggested  curve  (dotted 
line)  in  Tabs  B.7.1  and  B.7. 2.  (Also  see  discussion  on  hypothetical 
algorithm  in  Tab  B,  Section  1.1.3.)  It  is  suggested  that  for  Ig’ss  than 
60%  utilization,  the  60%  curve  be  used. 


MONTHS  OF  SOFTWARE  DEVELOPMENT 
TIME  VS.  CORE  UTILIZATION 

Tab  Page 

B.7.1  Up  to  100,000  source  instructions  B-46 

B.7. 2  Up  to  500,000  source  instructions  B-47 
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(UP  TO  500,000  SOURCE  INSTRUCTIONS) 


TAB  B . 8  MANMONTHS  OF  SOFTWARE  DEVELOPMENT  TIME 
VS.  CORE  UTILIZATION 


The  relationships  illustrated  in  this  set  of  Tabs,  B.8.1  and  B.8.2,  were 
developed  through  the  application  of  the  algorithm  (Equation  7)  discussed 
in  Tab  B,  Section  1.1.4.  These  curves  shew  the  relationships  between  the 
number  of  lines  of  source  instructions  that  are  to  be  developed,  and  the 
number  of  manmonths  of  effort  required  to  develop  them  considering  the 
impact  of  core  utilization.  Note  that  as  core  utilization  increases  from 
60%  to  100%  the  manmonths  of  effort  increases.  It  is  suggested  that  for 
less  than  60%  utilization,  the  60%  curve  be  used. 


MANMONTHS  OF  SOFTWARE  DEVELOPMENT  TIME 
VS.  CORE  UTILIZATION 
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B.8.1  Up  to  100,000  source  instructions  B-49 

B.8.2  Up  to  500,000  source  instructions  B-50 


TAB  B.9  FAST  STORAGE  CAPACITY  VS.  NUMBER  OF 
AIR  TARGETS  TRACKED 


The  relationships  illustrated  in  this  set  of  Tabs,  B.9.1  and  B.9. 2,  were 
developed  through  the  application  of  the  algorithms  (Equations  8  and  9) 
discussed  in  Tab  B,  Section  1.1.5.  These  curves  show  the  impact  on  fast 
storage  capacity  as  the  number  of  targets  tracked  and  approach  speed 
increase.  As  the  speed  of  the  target  increases,  or  as  the  number  of 
targets  tracked  increases,  the  number  of  words  of  fast  storage  increases. 
Fast  storage  is  defined  in  Tab  B,  Section  1.1.5. 


FAST  STORAGE  CAPACITY  VS.  NUMBER 
OF  AIR  TARGETS  TRACKED 
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B.9.1  Up  to  20  targets . B-52 

B.9. 2  Up  to  100  targets . B-53 
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STORAGE  CAPACITY  VS  NUMBER  OF  AIR  TARGETS  TRACKED 
(UP  TO  20  TARGETS) 
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TAB  B. 10  NUMBER  OF  INSTRUCTIONS  VS.  NUMBER  OF 
AIR  TARGETS  TRACKED 


The  relationships  illustrated  in  this  set  of  Tabs,  B.10.1  and  B.10.2,  were 
developed  through  the  application  of  the  algorithms  (Equations  10  and  11) 
discussed  in  Tab  B,  Section  1.1.5.  These  curves  show  the  impact  on  total 
operating  instructions  as  the  number  of  targets  tracked. 


NUMBER  OF  INSTRUCTIONS  VS.  NUMBER 
OF  AIR  TARGETS  TRACKED 
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B.10.1  Up  to  20  targets . B-55 

B.10.2  Up  to  100  targets . B-56 
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TAB  B.10.1  NUMBER  OF  INSTRUCTIONS  VS  NUMBER  OF  AIR  TARGETS  TRACKED 

(UP  TO  20  TARGETS) 


TAB  B. 11  NUMBER  OF  INSTRUCTIONS  VS.  FAST  STORAGE 
CAPACITY/AIR  TARGET  SPEED 


The  relationships  illustrated  in  this  Tab,  B.ll.l,  were  developed  through 
the  application  of  the  algorithms  (Equations  8  through  11)  discussed  in 
Tab  B,  Section  1.1.5.  These  curves  shew  the  relationships  between  the 
number  of  operating  instructions  to  the  number  of  words  in  fast  storage 
and  the  speeds  of  the  targets  tracked.  The  curves  illustrate  that  for 
larger  size  operational  software,  a  greater  proportion  of  the  total 
operating  software  is  required  to  be  resident  in  fast  storage.  Fast 
storage  is  defined  in  Tab  B,  Section  1.1.5. 
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NUMBER  OF  INSTRUCTIONS  VS  FAST  SOTRAGE  CAPACITY  AND  AIR  TARGET  SPEED 


TAB  C 
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CASE  1  -  EXAMPLE  OF  THE  APPLICATION  OF  PROCEDURES 
TO  AN  INITIAL  SIZING  AND  TIMING  STUDY 


A.  INTRODUCTION 

This  is  an  example  of  the  application  of  the  procedures  discussed  in 
Volume  I  of  this  handbook.  The  example  illustrates  a  number  of  the 
problems  that  can  be  encountered  in  conducting  a  sizing  and  timing  study, 
particularly  an  initial  study.  It  is  recommended  that  the  reader  refer  to 
the  handbook  sections  in  Volume  I  and  the  Tabs  of  both  volumes  cited 
throughout  this  example.  This  will  provide  a  better  understanding  of  the 
step-by-step  procedures  being  taken. 


B.  BACKGROUND 

At  the  recently  formed  Program  Office  for  FAR  VIEW,  Lt.  Sutter  has 
been  requested  to  conduct  an  initial  computer  system  sizing  and  timing 
study.  Having  reported  a  couple  of  weeks  earlier,  and  this  being  her 
first  sizing  and  timing  study  effort,  Lt.  Sutter  recalled  her  predecessor, 
Captain  Reeves,  mentioning  that  the  Handbook  of  Procedures  for  Estimating 
Computer  System  Sizing  and  Timing  Parameters  should  prove  of  value  in 
conducting  a  study.  Lt.  Sutter  obtained  the  FAR  VIEW  documentation  from 
her  files  and  the  handbook  from  her  bookshelf,  and  noted  from  a  program 
schedule  that  FAR  VIEW  was  near  the  end  of  the  Conceptual  Phase  of  its 
acquisition.  Seated  at  her  desk,  she  quickly  read  the  text  and  the 
introduction  sections  to  the  various  tabs,  and  also  scanned  the  rest  of 
the  contents  of  both  volumes.  With  that,  Lt.  Sutter  turned  to  Section  5 
of  the  handbook  and  began  to  follow  the  procedural  steps  for  an  initial 
sizing  and  timing  study  (see  Section  5.2). 

C.  DETERMINING  THE  OBJECTIVES 

1.  "Of  the  seven  suggested  objectives  listed  in  Section  5.2.1,  Lt.  Sutter 
knew  that  her  task  was  to  conduct  an  initial  estimation  of  the  sizing  and 
timing  parameters  of  the  computer  system  in  the  FAR  VIEW  project.  The 
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parameters  that  were  considered  the  most  vital  to  the  performance  of  the 
system  were  the  main  and  bulk  storage  capacities  and  the  terminal  response 
times;  more  specifically: 

•  The  main  storage  had  to  be  large  enough  to  handle  all 

core  resident  programs  and  data  requirements,  plus  have 
a  25  percent  reserve  capacity  for  future  growth  upon 
delivery. 

•  The  bulk  storage  had  to  be  large  enough  to  handle  all 

programs  and  data  requirements  of  the  system. 

•  The  response  time  at  the.  terminals  has  to  meet  user 

established  requirements. 

2.  As  for  the  resources  available  to  conduct  the  study,  Lt.  Sutter  knew 
she  was  the  only  one  tasked  to  do  the  study  and  that  time  was  of  the 
essence . 

3.  At  this  point  in  time,  Lt.  Sutter  assumed  that  she  would  use  only 
terms  with  standard  definitions  (see  glossary  in  Volume  I  of  handbook), 
and  surmised  that  in  the  event  unusual  terms  were  required,  she  would 
ensure  that  definitions  were  provided  in  the  study  documentation. 

4.  Considering  that  the  FAJR  VIEW  project  was  near  the  end  of  the  Con¬ 

ceptual  Phase,  and  having  previously  reviewed  the  project  documentation 
she  had  in  file,  Lt.  Sutter  estimated  that  the  anticipated'  degree  of 

accuracy  of  the  final  study  results  could  be  in  error  by  at  least  100 
percent. 

5.  Although  the  study  was  for  the  internal  use  of  the  Program  Office,  Lt. 
Sutter  planned  to  include  ESD/TOI  in  the  distribution  so  that  a  copy  of 
the  report  would  be  retained  in  their  sizing  and  timing  study  repository. 

D.  DEFINE  SYSTEM  BOUNDARIES  AND  WORKLOADS 

1.  In  an  attempt  to  define  the  system's  boundaries  and  WJrkloads  (see 
Section  5.2.2),  Lt.  Sutter  reviewed  the  system  documentation  that  was  in 
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.  i  e  s ;  a  S 


'.atement  of  Work  (SOW)  for  FAR  VIEW,  a  System 


Specification,  and  a  Data  Requirements  Package. 


'.e  SOW,  L" 


noted  the  fallowing  as  having  possi1  le  impact  on  the  system’s 
timing  parameters: 


•  The  contractor  was  to  perform  a  functional  analysis 
using  the  system  operational  concepts. 

•  Each  subsystem  was  to  be  allocated  a  set  of  performance 
parameters,  and  the  contractor  was  to  conduct  an 
engineering  analysis  of  the  FAR  VIEW  System  Specifi¬ 
cation  and  prepare  the  Configuration  Identification 
documentation. 

•  The  contractor  was  also  to  conduct  tradeoff  studies  in 
an  effort  to  optimize  the  performance  parameters. 

•  Software  development  by  the  contractor  was  to  be 
performed  according  to  modern  programming  techniques. 

•  The  software  language  prescribed  for  FAR  VIEW  was  to  be 
JOVIAL;  however,  exceptions  could  be  made  for  highly 
used  algorithms. 

•  The  contractor  was  to  propose  off-the-shelf  computer 
system  equipment  to  the  maximum  extent  possible. 

The  System  Performance  Specification  contained  the  following  information 
of  value: 


•  FAR  VIEW  was  defined  as  a  single  unit,  new  fixed  phased 
array  warning  system,  that  was  to  be  used  to  detect 
ICBMs  in  a  designated  sector  of  air  space.  The  selec¬ 
tion  of  the  location  for  the  system  facility  was  in  its 
final  stages  of  approval. 

•  The  system  would  consist  of  a  radar  subsystem,  a  data 
processing  subsystem,  a  communications  subsystem,  and  a 
facilities  subsystem. 

•  FAR  VIEW  must  perform  the  following  functions  in  order 
to  accomplish  and  support  its  primary  mission  of  detec¬ 
ting  incoming  ICBMs,  and  predicting  their  time  and 
point  of  impact: 


surveillance 

tracking. 
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reporting, 

radar  scheduling  and  control, 
performance  monitoring, 
displays  and  controls, 
simulation,  exercises  and  tests, 
data  recording  and  reduction, 
maintenance  and  diagnostics, 
mission  planning,  and 
special  search  and  track  requests. 

The  maximum  of  projected  ICBMs  in  the  designated  sector 
of  air  space  was  estimated  to  be  80. 

Four  identical  display  consoles  were  to  be  provided. 
Each  console  would  normally  perform  one  of  the  follow¬ 
ing  functions: 

systems  operations,  monitoring  and  control, 
missile  warning  operations, 

train!  :  (also  as  back  up  for  other  consoles) ,  and 
maintenance  monitoring  and  control. 

Each  console  was  to  have  the  capability  to  handle 
operators  messages  and  provide  both  tabular  and  graphic 
displays. 

Detailed  console  display  requirements  were  delineated 
in  the  System  Performance  Specification. 

Software  programs  were  to  include  the  following  as  a 
minimum: 

executive  control  program  that  included  9  desig¬ 
nated  functions, 

functional  and  application  programs  that  contained 
monitoring  and  calibration  software  must  be 
on-line  with  the  operational  programs, 

diagnostic  programs  that  must  be  disc  resident, 

simulation  programs  must  be  on-line  with  the 
operational,  monitoring,  and  calibration  programs, 
and 

support  programs  for  the  above  must  be  provided. 

Tactical  messages  were  delineated  in  the  System  Perfor¬ 
mance  Specification. 


•  Response  time  from  missile  acquisition  to  display  of 
missile  warning  message  on  console  was  not  to  exceed 
the  time  required  for  the  signal  processing  function 
plus  the  minimum  data  processing  time. 

•  The  time  required  for  an  Impact  and  Time  (1ST)  message 
to  be  displayed  on  a  console  was  not  to  exceed  the  time 
required  for  the  signal  processing  function  and  neces¬ 
sary  calculations  to  provide  the  data  in  th  I&T  message. 

The  Data  Requirements  Package  did  not  provide  any  sizing  and  timing 
data. 

The  only  definition  of  a  workload  was  the  identification  of  the 
maximum  number  of  projected  ICBMs  (80  total)  that  would  require  tracking, 
monitoring  and  analysis  at  any  one  period  of  time,  plus  the  times  required 
for  console  displayed  data. 


2.  Lt.  Sutter  drew  a  block  diagram  of  the  computer  system  as  she  envis¬ 
ioned  it,  and  also  made  a  list  of  software  characteristics  based  on  the 
information  she  had  obtained  above.  She  had  not  identified  any  informa¬ 
tion  in  the  project  documentation  regarding  software  sizing. 

3.  At  this  point,  Lt.  Sutter  wondered  aloud  whether  she  would  be  able  to 
achieve  the  study  objectives;  however,  she  considered  the  next  step  in  the 
sizing  and  timing  procedures  and  decided  to  continue  with  her  initially 
established  study  objectives. 

E.  ESTABLISH  CANDIDATE  TECHNIQUES  (see  Section  5.2.3) 

Realizing  that  she  did  not  have  too  many  details  regarding  the  FAR 
VIEW  system,  Lt.  Sutter  reviewed  the  illustration  of  sizing  and  timing 
techniques  in  Figure  6,  and  the  discussion  in  Tab  A  of  Volume  I  of  the 
handbook.  She  came  to  the  conclusion  that,  due  to  the  lack  of  system 
sizing  and  timing  data,  she  should  try  using  analogies  and  possibly  some 
analytical  techniques  if  enough  possible  parameters  or  data  could  be 
obtained.  She  also  made  a  note  of  the  confidence  level  of  the  candidate 
techniques. 


F .  IDENTIFY  AND  QUALIFY  DATA  SOURCES  (see  Section  5.2.41 

It.  Sutter  reviewed  Tab  A,  Volume  II  ■~'f  the  handbook  a:,d  a  r*'por‘  of 

ESD  C3  system  acquisitions  and  noted  that  there  w-re  twc  ether  . h a  d- 

array  radar  systems  that  were  to  perform  functions  imilar  to  FAR  VIEW, 
though  the  hardware  of  the  two  computer  systems  was  somewhat  different. 

In  addition,  Lt.  Sutter  contacted  other  staff  members  of  FAR  VIEW  Program 
Office  and  obtained  a  copy  of  the  contractor's  proposal  that  provided  a 
listing  of  the  hardware  he  proposed  and  his  estimate  of  software  size. 

G.  PREPARE  DETAILED  STUDY  APPROACH 

Following  the  guidance  in  Section  5.2.5,  Lt.  Sutter  prepared  a 

detailed  study  plan.  She  defined  the  FAR  VIEW  system  boundaries  based  on 
the  information  she  had  obtained  from  the  System  Performance  Specification 
and  the  contractor's  proposal  (see  Sections  D.l  and  F  above).  Listing 
constraints  and  assumptions,  Lt.  Sutter  noted  under  constraints  that  FAR 
VIEW'S  workloads  could  not  be  defined  and  that  timing  data  for  FAR  VIEW 
did  not  exist  except  for  a  few  parameters  cited  in  the  System  Performance 
Specification.  As  for  assumptions,  Lt.  Sutter  noted  that  two  other 
phased-array  radar  systems  performed  similar  functions,  therefore, 
correlations  might  be  made  between  the  functions,  software  and  data  sizes, 
hardware  requirements,  and  maybe  even  workloads.  Also,  she  made  the 
assumption  that  the  reserve  memory  capacity  of  the  two  systems  was  between 
20-25  percent  and  that  the  data  bases  were  approximately  the  same. 

H.  CONDUCT,  CORRELATE  AND  ANALYZE  STUDY  (see  Sections  5.2.5  through  5.2.8) 

In  order  to  compare  similar  equipments  and  functions,  Lt.  Sutter 

developed  a  table  of  data  regarding  the  three  systems.  The  table  below 
illustrates  some  of  the  highlights  of  Lt.  Sutter's  comparison  table  that 
went  into  considerable  detail,  such  as  descriptions  of  each  software  and 
/stem  function,  etc. 
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r 

— 

FAR  VIEW 

SYSTEM-A 

SYSTEM-B 

1 

• 

System 

1-CDC  CYBER  174-12 
( proposed  1 

1-CDC  CYBER  74-18 

1 -UNI VAC  1110 

.  • 

Main  Memory 

198K-60  bit/words 

120K-60  bit/words 

110K-26  bit/words 

i  • 

Cycle  Time 

0.4  microsec 

1.0  microsec 

0. 52  microsec 

1  • 

Tape  Drives 

3  ea 

2  ea 

4  ea 

• 

Disc  Units 

2  ea 

2  ea 

2  ea 

• 

Displays 

4  CDC  777 

5  CDC  243-2 

3  UNI VAC 

• 

Software  Size 

200K  deliverable 

400K  object 

440  K  object 

; 

(Estimate) 

source  statements 

sta  tements 

sta  tements 

• 

Breakdown  by 
S/W  functions 

12 

Not  available 

Not  available  j 

i 

1  • 

Source  to 
Object  Code 
Conversion 
Ratio 

1:2 

1:2 

1  3 

• 

Data  Size 

Not  available 

Not  available 

Not  available 

(Estimate) 

(See  assumptions) 

(See  assumptions) 

(See  assumptions) 

• 

System 

Functions 

12 

14 

9 

• 

_ 

Maximum  Num¬ 
ber  Targets 

80 

Not  available 

Not  available 

Based  on  Lt.  Sutter's  analysis  of  her  detailed  comparison  table,  she 
concluded  that  the  proposed  computer  system  for  FAR  VIEW  appeared  adequate 
to  perform  the  functions  required,  including  those  of  the  operating 
system;  however,  she  could  not  quantify  the  bulk  storage  available  nor  the 
estimated  terminal  response  times.  By  using  Equation  1  cited  in  Tab  B, 
Volume  II  of  the  handbook,  Lt.  Sutter  calculated  that  the  required 
capacity  for  both  programs  and  data  in  the  main  memory  could  be 
approximately  135  thousand  object  words,  assuming  that;  the  primary 
application  was  signal  processing;  twelve  major  functions  were  to  be 
performed  by  the  software;  the  word  size  was  a  60  bit-word;  and  the  cycle 
time  was  0.4  microseconds.  Considering  another  68  thousand  object  words 
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for  reserve  capacity  (using  Equation  1  cited  in  Section  6.2,  Volume  T  of 
the  handbook  this  reserve  capacity  equated  to  33  percent  of  the  total 
available  memory),  Lt.  Sutter  noted  that  the  total  approximately  equalled 
the  main  memory  capacity  of  the  proposed  computer.  It  should  he  noted 

that  Lt.  Sutter  correctly  identified  the  primary  application  of  the  ECS  as 
signal  processing  and  used  the  constant  for  signal  processing  in  the 
equation.  Had  she  considered  the  application  as  command  and  control,  and 
used  that  constant  in  the  equation,  the  solution  to  the  calculation  would 
have  indicated  that  approximately  four  times  more  memory  capacity  would  be 
required.  This  larger  capacity  estimate  would  not  have  been  consistent 

with  her  analogy  comparison  table  data,  and  would  hopefully  have 

encouraged  LT.  Sutter  to  evaluate  the  disparity.  The  point  that  Lt. 

Sutter  and  the  readers  should  remember  in  estimating  efforts  is  to 
consider  as  many  data  points  as  possible  and  the  level  of  confidence  of 
each  data  point. 

I.  PREPARE  THE  STUDY  REPORT  (see  Section  5.2.9) 

Lt.  Sutter  structured  her  report  as  suggested  by  the  handbook.  In  the 
report,  she  emphasized  that  initial  estimates  near  the  end  of  the 
Conceptual  Phase  could  be  in  error  by  100  percent,  and  cited  the  paucity 
of  sizing  and  timing  data,  especially  workloads.  She  discussed  the 
comparison  of  the  three  computer  systems  and  concluded  that  the  proposed 
system  for  FAR  VIEW  appeared  reasonable;  therefore,  it  could  be  assumed 
that  bulk  storage  requirements  would  be  met.  Acknowledging  the  large 
error  possibility,  the  main  memory  capacity  also  appeared  reasonable, 
though  she  also  recommended  close  monitoring  of  the  software  development, 
as  well  as  any  possible  growth  in  user  requirements  for  more  data.  She 
also  commented  on  the  fact  that  without  the  workloads,  she  was  unable  to 
estimate  response  times.  In  completing  the  report,  Lt.  Sutter  included  a 
recommendation  that  the  study  report  be  brought  to  the  attention  of  the 
contractor  and  the  user  organization.  As  soon  as  the  report  was  prepared, 
Lt.  Sutter  submitted  it  and  made  a  mental  note  to  discuss  the  report  with 
ESD/TOI . 
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IASE  2  -  EXAMPLE  OF  THE  APPLICATION  OF  PROCEDURES 
TO  DEVELOPMENTAL  MONITORING 


A.  BACKGROUND 

The  SKY  WATCH  project,  the  development  of  radar  warning  system,  is  in 
the  sixteenth  month  of  Full-Scale  Development  (FSD) .  The  FSD  phase  is 
scheduled  for  36  months  and,  until  the  last  month,  appears  to  have  been 
going  well,  even  though  the  initial  Preliminary  Design  Review  ( PDR)  and 
the  Critical  Design  Reviews  (CDR)  slipped  by  about  3  months  each.  The  CDR 
for  CPCT  No.  1,  RDRSWTC  (radar  switching),  was  conducted  and  resulted  in 
the  following  breakdown  in  terms  of  lines  of  code: 

CPCI  »  CPCs  ♦  MODULES  ESTIMATED  SOURCE  CODE 

RDRSWTC  15  56  12,000 

* 

This  breakdown  has  changed  since  the  original  submission  of  the 
Computer  Program  Development  Plan  (CPDP) .  The  original  and  revised 
estimates  for  CPCI  RDRSWTC  are  as  follows: 


ORIGINAL 

REVISED 

ESTIMATED 

EXISTING  CODE 

6 ,000F* 

4 , 000F 

NUMBER 

CONVERSION  CODE 

2 , 000F 

2 , 250F 

OF 

NEW  CODE 

2 , 000F 

5 , 750F 

INSTRUCTIONS 

TOTAL  CODE 

10 , 000F 

12 , 000F 

ANALYSIS 

J 

10** 

ESTIMATED 

DESIGN 

18 

20** 

EFFORT 

CODE  AND  CHECKOUTS 

12 

12 

IN 

TEST  AND  INTEGRATION 

24 

18 

MANMONTHS 

TOTAL  THROUGH  INTEGRATION 

60 

60 

*F  Denotes  FORTRAN 

**Actual  Expenditures 


Discussions  with  the  contractor  have  resulted  in  less  than  satis¬ 
factory  answers  regarding  the  mix  of  code  types  within  the  12,000  lines  of 
source  code.  The  question  has  been  raised  on  the  breakdown  of  executable, 
nonexecutable,  comment,  and  data  definition  code.  The  definition  of  this 
breakdown  is  important  in  the  ultimate  memory  requirement  in  terms  of 
words  of  storage,  and  also  in  the  resources  required  to  develop,  test  and 
integrate  the  CPCI. 

The  Sizing  and  Timing  Officer  (S&TO)  has  been  tasked  with  providing 
developmental  monitoring  reports  on'  the  progress  of  the  developed  computer 
programs.  The  current  emphasis  is  on  the  verification  of  the  estimated 
size  of  the  programs  and  whether  the  estimated  resources  and  development 
time  are  sufficient.  In  addressing  CPCI  RDRSWTC  for  month  16,  the  S&TO 
proceeded  in  accordance  with  paragraph  B.  below. 

B.  PROCEDURE  APPLICATION  (reference  Section  5.4,  Volume  I) 

1.  Prepare  Prediction  Set 

The  prediction  set  for  the  value  of  the  total  source  code  for  CPCI 
RDRSWTC  (one  of  several  sets) ,  was  prepared  and  is  shown  in  Figure  C-l. 
This  shows  that,  as  of  the  completion  of  the  month  15  monitoring,  the 
beginning  prediction  value  of  source  lines  of  code  was  12,000,  and  that 
the  estimated  value  after  analysis  was  13,000  lines.  This  value  of  13,000 
is  not  the  value  that  will  be  the  "LAST  VALUE"  in  month  17,  and  the 
estimate  to  be  done  herein  will  be  the  "PREDICTED  VALUE  AS  OF  THIS  DATE" 
for  month  17.  Items  6,  7,  and  8  will  be  entered  upon  completion  of  this 
month's  (month  16)  estimate. 

2.  Verify  Analysis  Techniques 

There  were  two  assumptions  that  have  been  used  in  the  development  of 
size  and  resource  estimates.  These  two  assumptions  must  be  verified  as 
the  coding  and  testing  progresses.  First,  there  is  the  set  of  relation¬ 
ships  dealing  with  the  conversion  from  FORTRAN  source  statements  to  words 
of  core.  It  has  been  stated  that,  based  on  one  object  instruction  per 
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object  word,  an  expansion  ratio  of  1:5  would  be  used.  This  means  that  for 
every  FORTRAN  source  statement  there  would  be  5  object  instructions,  and 
with  the  1:1  instruction  to  word  ratio,  5  words  of  memory  required.  It 
has  never  been  clear  as  to  what  this  ratio  was  based  on;  that  is,  whether 
the  instruction  mix  was  similar  to  that  required  for  radar  switching. 
However,  the  contractor  assured  the  PO  that  COMMENT  lines  were  excluded 
from  the  count  of  source  code  used  to  derive  the  ratio. 

The  second  assumption  that  has  been  made  is  that  the  code  would  be  of 
"medium"  conplexity.  It  is  also  not  clear  what  this  means.  Many  estima¬ 
ting  algorithms  break  productivity  into  HARD,  MEDIUM,  and  EASY  difficulty 
groups.  The  S& TO  has  rightly  made  the  decision  to  try  to  back-fit  actual 
code  production  into  actual  resources  used  in  order  to  estimate  the 
difficulty. 

Based  upon  12,000  lines  of  source  code,  all  of  which  are  to  be 
delivered,  the  memory  requirement  to  support  the  CPCI  would  be  60,000 
words  of  storage.  The  memory  budget  for  CPCI  RDRSWTC  is  currently  64K 
words,  not  including  data. 

The  initial  estimates  for  the  15  CPCs  were  based  on  historical  data 
from  a  previous  system.  Adjustments  have  been  made  to  account  for  dif¬ 
ferent  word  length  and  instruction  length;  however,  in  view  of  the  fact 
that  all  coding  is  to  be  done  in  FORTRAN,  estimated  resources  were  based 
on  prior  corporate  history.  One  thing  that .Ijas  bothered  the  SSTO  is  that 
the  function  of  TASKING  CALIBRATION  within  CPCI  RDRSWTC  is  not  clearly 
defined.  This,  along  with  the  prior  behind  schedule  performance  in  the 
conduct  of  reviews,  has  resulted  in  the  previous  increase  in  estimated 
code  count  of  1,000  source  lines.  The  SSTO  is  looking  for  the  completed 
coding  and  compilation  of  four  modules,  or  about  800  lines  of  code. 
Module  sizes  have  been  running  larger  than  the  100  lines  established  as  a 
goal,  but  the  contractor  has  been  firm  in  his  view  that  modules  of  100 
lines  cause  excess  record  keeping  and  inefficient  coding. 
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3.  Receive  Data  or  Request  Update. 

The  S&TO  has  received  the  following  data  items  as  monthly  inputs: 

a.  DI-S-30568  -  Computer  Program  Sizing  and  Timing  Data,  and 

b.  DI-F-6000B  -  Cost  Performance  Report  (CPR) . 

DI-S-30568  still  indicates  that  CPCI  RDRSWTC  is  estimated  at  12,000 
lines  of  source  code.  However,  there  was  a  statement  from  the  contractor 
indicating  that: 

...due  to  the  continued  definition  of  the  degree  of 

complexity  of  CPCI  RDRSWTC,  it  has  been  necessary  to 

modify  the  approach  for  the  coding  of  CPC  #2. 

CPC  #2  contains  the  four  modules  that  were  due  to  be  coded  during  the 
previous  month.  The  question  that  the  S&TO  immediately  asked  was,  "How 
much  code  was  developed  last  month?"  The  contractor  promised  to  return 
with  the  answer. 

Looking  at  the  Cost  Performance  Report,  the  Cost  Account  reflecting 
the  budgets  for  CPC  #2  indicated  3  marunonths  for  CODE  &  CHECKOUT  and  TEST 
&  INTEGRATION.  This  did  not  seem  to  correlate  with  the  revised  CPDP  that 
showed  only  30  marunonths  for  the  CODE  &  CHECKOUT  and  TEST  &  INTEGRATION  of 
all  15  CPCs,  with  a  total  of  12,000  lines  of  code.  Taking  the  total  60 
marunonths  and  checking  back,  the  S&TO  found  that  the  contractor  had  allo¬ 
cated  4  marunonths  for  each  CPC  to  go  from  ANALYSIS  through  TEST  &  INTEGRA¬ 
TION,  This  was  based  on  an  estimated  productivity  of  166  source  lines  per 
manmonth,  but  this  was  the  resource  for  the  initial  estimate  of  10,000 
lines.  Code  count  has  increased  by  2,000  lines,  with  resources  remaining 
the  same.  Looking  at  actual  resources  expended  in  the  analysis  and  design 
phases  of  CPCI  RDRSWTC,  50%  of  the  resources  (30MM/60MM)  have  been 
expended.  This  leaves  only  20%  cor  CODE  &  CHECKOUT  and  30%  for  TEST  & 
INTEGRATION.  With  the  CPR  indicating  3  marunonths  for  CODE  &  CHECKOUT, 
that  leaves  only  9  marunonths  for  the  other  14  CPCs  that  contain  about 
11,200  lines  of  code.  If  the  20%  factor  is  anywhere  near  accurate,  this 
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.Deans  that  the  resources  for  11,200  Lines  of  code  weald  he  45  Tar  month  3 
(9  .2),  that  would  yield  a  required  overall  productivity  of  243  lines  per 
man-month.  The  S&TO  updated  his  Preliminary  Data  Pile  by  completing  a 
Prediction  Set  form  based  on  the  above  information. 

4.  Perform  Analysis 

Based  on  the  above,  the  S&TO  went  back  to  the  software  engineer  in  the 
PO  and  the  Business  Manager,  and  asked  the  following  questions.  The 
answers,  that  took  one  week  to  obtain,  are  shown  with  the  question: 

Q:  Is  the  analysis  and  design  complete  for  CPCI  RDRSWTC? 

A:  Yes. 

Q:  How  many  modules  and  associated  code  were  to  have  been 

developed  and  compiled  as  of  the  last  reporting  period? 

A:  800  lines. 

Q:  How  much  has  been  completed? 

A:  200  lines. 

Q:  Is  the  analysis  and  design  complete  for  the  entire  CPCI? 

A:  Yes. 

Q:  50%  of  the  resources  have  been  expended  in  ANALYSIS  & 

DESIGN  alone.  How  much  of  the  CODE  &  CHECKOUT  budget 
has  been  expended? 

A:  1.5  manmonths. 

At  this  point  the  S&TO  is  greatly  concerned.  First,  what  appeared  to 
originally  be  a  reasonable  budget  for  CODE  &  CHECKOUT  of  12,000  lines  of 
code  (12  manmonths,  that  is  20%  of  the  entire  budget  of  60  manmonths),  now 
appears  to  be  in  trouble.  12.5%  of  the  budget  has  been  expended  to 
develop  only  1.6%  of  the  total  code  (200/12,000).  The  S&TO  reviews  the 
established  factors  for  software  development  and  finds  that  the  widely 
used  split  is: 

•  40%  Analysis  &  Design, 

•  20%  Code  &  Checkout,  and 

•  40%  Test  &  Integration. 

These  factors  agree  fairly  well  with  the  estimates  of  the  resources 
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•  50%  Design  &  Analysis  (a  little  heavy), 

•  20%  Code  &  Checkout,  and 

•  30%  Test  &  Integration. 

Even  the  total  resources  of  60  manmonths  for  12,000  lines  of  code, 
that  gives  200  lines  of  delivered  and  checked-out  code  per  manmonth,  is 
within  the  range  of  medium  complexity  code. 

The  S&TO  now  is  convinced  that  one  of  two  things  has  happened.  First, 
the  complexity  of  the  code  is  greater  than  anticipated,  as  shown  by  heavy 
actuals  in  Design  &  Analysis  (50%  of  budget)  and  the  high  initial  core 
utilization  of  93%  (60K/64K) ;  and  second,  the  lack  of  progress  in  deliv¬ 

ered  code  with  high  resource  consumption  shows  there  is  every  probability 
that  core  will  be  exceeded.  This  last  observation  was  confirmed  when  the 
contractor  acknowledged  that  500  lines  of  code  were  thrown  away  during  the 
month. 

5.  Prepare  Report 

The  thrust  of  the  S&TO  report  to  the  Program  Manager  is  that  there 
appears  to  be  a  serious  problem,  based  on  performance  to  date,  with  the 
size  of  CPCI  RDRSWTC.  From  experience,  the  S&TO  knows  that  the  lack  of 
progress  in  the  development  of  software  is  very  often  the  forerunner  of 
increased  size.  As  of  this  report  he  has  no  estimate  of  what  the  eventual 
size  will  be,  but  he  strongly  recommends  a  SIZING  AND  TIMING  STUDY  UPDATE 
be  conducted. 

6.  Update  Data  File 

The  Prediction  Set  form  is  updated  to  note  that  the  estimate  of  13,000 
lines  of  code  is  highly  suspect.  In  block  7,  the  S&TO  notes  that  there 
has  been  very  little  progress  in  the  coding  of  CPCI  RDRSWTC. 

7.  Corrective  Action 

The  conduct  of  an  updated  sizing  and  timing  study  for  CPCI  RDRSWTC 


will  be  undertaken 


TAB  D  PROPOSED  REVISION  OF  DID  (DI-S-30568) 


This  Tab  contains  a  proposed  revision  of  the  Data  Item  Description  (DID! 
entitled,  Computer  Program  Timing  and  Sizing  Data  (DI-S-30568). 

Computer  Program  Timing  and  Sizing  Data  (DI-S-30568)  .  D-2 

Proposed  Revision  of  DID .  D-3 


D-l 


Computer  Program  fining  and  Siting  Data _ 

S  C  (  *C  •'•TiON 

This  DID  Is  used  to  obtain  both  estimated  and  actual  com¬ 
puter  program  memory  sire  requirements,  computer  program 
timing  requirements  and  Computer  Program  Configuration  Item 
(CPCI)  Interface  data. 


’  APPLICATION  INt(KNtk  ATIOMMiP 

This  DID  is  designed  for  use  in  conjunction  with  the  Computer 
Program  Development  Specification  0 1  - E - 301  39  ,  Com¬ 
puter  Program  Product  Specification  CI-E-33140  and 

Common  Data  Base  Design  Specification  JI-E-33144  This 
DID,  along  with  the  above  mentioned  Specifications,  apply  to 
all  Computer  Program  Configuration  Items  (CPCIs). 


APR  800-14,  VOL  II, 
dated  26  Sep  75 


Formerly.  LiS- 331  3 - ASD 

1C  BKIt  AHI’ICS  NjtB.CVONJ 

1.  General  Requirements.  The  Timing  and  Sizing  Data  shali  describe  in  detail  the 
CPCI  timing  data,  memory  utilization  data  and  Interface  data.  However,  this  DID 
shall  not  unnecessarily  duplicate  descriptive  material  presented  In  other  documents. 

2.  Detailed  Requirements.  For  convenience  in  describing  the  minimum  essential 
content,  the  following  paragraphs  show  a  normal  format  for  presentation  of  the  material 
In  the  following  description,  paragraph  headings  and  numbers  indiccte  the  general 
nature  of  the  topic,  and  are  minimum  mandatory  requirements. 

a.  Section  1  -  Scope.  This  section  shall  introduce  the  document  and  summarize 
the  interface  conventions  used. 

b.  Section  2  -  Applicable  Documents.  This  section  shall  contain  references  to 
the  appropriate  Computer  Program  Product  Specification,  Computer  Program  Development 
Specification,  Common  Data  Base  Design  Specification  and  any  additional  documents, 
that  apply  to  the  design  or  use  of  the  Timing  and  Sizing  Data. 

c.  Paragraph  3  -  Interface  Drawings.  This  paragraph  shall  completely  describe 
the  Interface.  Functional  interfaces  between  CPCIs  within  a  system  shall  be  identi¬ 
fied  in  terms  of  specific  input  and  output  data,  data  rates,  message  formats,  message 
contents,  data  units  and  accuracies,  and  operational  limits.  The  Interface  between 
CPCIs,  the  computers,  and  the  associated  equipment  shall  be  defined  in  terms  of 

such  relevant  characteristics  as  memory  size,  word  size,  process  and  operational  times. 
Interrupt  capabilities,  Inputs  and  outputs,  buffers  and  special  capabilities. 
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PROPOSED  REVISION  OF  DID 

COMPUTER  PROGRAM  TIMING  AND  SIZING  DATA  -  DI-S-3G568 


PROPOSED  CHANGES  AND  REVISIONS  .ARE  UNDERLINED . 

BLOCK  PROPOSED  BLOCK  CONTENT 

1.  Computer  Frogram  Sizing  and  Timing  Data 

2.  USAF  DI-S-30568A 

3.  This  DID  is  used  to  obtain  both  estimated  and  actual  com¬ 
puter  program  memory  size  requirements,  computet  program 
timing  requirements  and  Computer  Program  Configuration  Item 
(CPCI)  interface  data.  I;.  addition,  the  data  is  correlated 
with  the  same  data  provided  by  other  contract  deliverable 
DIDs  to  insure  that  any  changes  or  revisions  are  reflected 
in  all  documents. 


4  . 

No  Change. 

Blank. 

5. 

No  Change. 

Blank . 

6  . 

No  Change. 

Blank . 

7  . 

This  DID 

is  designed  for  use  ir.  conjunction  with  the 

Computer  Program  Development  Spec : ri cat  ion  DI-E-30139, 
Computer  Program  Product  Specification,  DI-E-3014u,  and 
Common  Data  Base  Desigt  Specification,  DI-E-30144,  and 
Computer  Program  Development  Plan  (CPDP. ,  DI-S-30567A.  In 


addition,  if  the 

requirements  of  the 

Cost/ Schedule 

Control 

Systems  Criteria 

(C/SCSC) 

are  invoked 

,  generate’  cost  and 

performance  data 

shall  be 

traceable 

from  required 

C/SCSC 

reports  to  reports  gene.ated  under  this  DID.  This  DID, 
along  with  the  above  mentioned  specifications  and  develop¬ 
ment  plan,  applies  to  all  Computer  Program  Configuration 
Items  (CPCIs) . 

3.  No  Change.  Blank. 

i .  No  Change.  AFR  800-14,  Vol  II,  dated  26  September  1975. 

10.  1.  General  Requirements.  The  s i z i ng  a  nd  timing  data  shall 

describe  in  detail  the  CPCI,  CPC,  and  module  timing  data, 
memory  utilization  data,  manpower  resource  data,  schedule 
data  and  interface  data.  Applicable  data  submitted  in 
compliance  with  other  DIDs  shall  be  transferred  directly  to 
the  appropriate  format  prescribed  by  this  DID. 

2.  Detailed  Requirement-;.  The  following  paragraphs  show  the 
normal  format  for  presentation  of  the  minimum  required 
mater ial. 
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PROPOSED  REVISION  OF  DID 

COMPUTER  PROGRAM  SIZING  AND  TIMING  DATA  -  DI-S-30568 


PROPOSED  CHANGES  AND  REVISIONS  ARE  UNDERLINED. 


BLOCK  PROPOSED  BLOCK  CONTENT 


10. 


2.  a.  Section  1  -  Scope.  This  section  shall  introduce  the 
document  and  summarize  the  interface  conventions  used. 
Special  emphasis  shall  be  placed  on  describing  how  all 
the  applicable  contract  documents  dealing  with  software 
sizing  and  timing  are  presented  in  this  deliverable. 


b.  Section  2  -  Applicable  Documents.  This  section  shall 
list  all  (underline  all)  related  contractual  documents 
dealing  with  computer  program  sizing  and  timing.  The 
display  of  these  documents  shall  be  in  a  form  similar 
to  Format  No.  1  attached  herein.  Not  only  shall  the 
document  nomenclature  be  presented,  but  also  the 
specific  paragraph,  the  date  of  the  document,  approval 
status,  and  whether  the  type  of  information  presented 
is  different  from  that  of  the  prior  document. 


c*  Section  3  -  Computer  Program  Breakdown.  This  section 
shall  list  all  computer  products  indicating  the 
structural  relationships  among  CPCIs,  CPCs,  and 
modules.  In  addition,  any  computer  programs  not  being 

developed  or  processed  under  this  contract,  but  which 

could  be  resident  in  the  embedded  computer  system,  such 
as  system  text  software,  shall  be  described  so  as  to 

include  memory  budget  for  all  programs  and  associated 
data.  Computer  programs  shall  be  displayed  in  a  form 
similar  to  Format  No.  2  attached  herein.  It  should  be 
noted  that  resource  data,  that  is  required  by  manage¬ 
ment  systems  such  as  the  Cost/Schedule  Control  Systems 
(C/SCSC) ,  shall  be  included.  Resource  data  shall  be 

the  most  current  data  that  has  been  p.ovided  by  the 
applicable  Cost  Performance  Report,  Cost  Schedule 
Status  Report,  or  other  documents. 

d.  Section  4  -  Interface  Drawings.  This  section  shall 

completely  describe  the  interfaces.  Functional  inter¬ 
faces  between  CPCIs  within  a  system  shall  be  identified 
in  terms  of  specific  input  and  output  data,  data  rates, 
message  formats,  message  contents,  data  units,  includ¬ 
ing  accuracies  and  operat.onal  limits.  The  interfaces 
between  CPCIs,  the  computers,  and  the  associated 
equipment  shall  be  defined  in  terms  of  such  relevant 
characteristics  as  memory  size,  word  size,  process  and 
operational  times,  interrupt  capabilities,  inputs  and 
outputs,  buffers  and  special  capabilities. 
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PROPOSED  REVISION  OF  DID 

COMPUTER  PROGRAM  SIZING  AND  TIMING  DATA  -  DI-S-30568 


PROPOSED  CHANGES  AND  REVISIONS  ARE  UNDERLINED. 
BLOCK  PROPOSED  BLOCK  CONTENT 


Section  5  -  Measurement  Conventions.  This  section  shall 
provide  the  conventions  used  to  generate  the  data 
displayed  in  Format  No.  2.  For  example,  the  specific 
algorithms  used  to  calculate  reserve  core,  per  cent  of 
core  utilization,  and  the  basis  for  initial  module 
estimates,  sequencing  and  maximum  run-times.  DO  NOT 
use  explanations  such  as  "Engineering  Judgement"  or 
"Similar  Systems"  without  further  explanation.  Each 
category  of  measurement  convention  shall  be  identified 
by  a  reference  code,  such  as  "Cl  =  spare  core  conven¬ 
tion,"  or,  "El  =  estimated  code  count  based  upon  module 

ABC  of  system  XYZ."  Reference  codes  shall  be  used  in 

Format  No.  2.  Definitions  shall  be  provided  for  all 

uerms  such  as  "source  code"  (with  or  without  com¬ 

ments?)  ,  which  may  be  subject  to  misinterpretation. 
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FORMAT  2b 


COMPUTER  PROGRAM  SIZING  AND  TIMING  DATA  -  DI-S-30568A 


COMPUTER  PROGRAM  BREAKDOWN  -  CPC I  Level 
(Use  a  r.eparate  sheet  for  eacL  CPC) 


PARENT  CPCI  IDENTIFICATION: 


SIZE  DATA 


TYPE  LANGUAGE 


INITIAL  ESTIMATE 

CURRENT  ESTIMATE 

SOURCE  OBJECT  WORDS 

SOURCE  OBJECT  WORDS 

EXISTING  CODE 
CONVERSION  CODE 
NEW  CODE 
TOTAL  CODE 


RESOURCE  REQUIREMENTS 


ESTIMATED  EFFORT 
IN  MANMONTHS 


INITIAL 

ESTIMATE 


REVISED 

ESTIMATE 


ACTUALS  TO  DATE 
AS  OF 


ANALYSIS 

DESIGN 

CODE  fc  CHECKOUT 
TEST  6  INTEGRATION 
INSTALLATION 
OPERATION  &  SUPPORT 
DOCUMENTATION 
OTHER 

TOTAL  MANMONTHS 


TIMING  BUDGET 

BUDGET 

CURRENT  ESTIMATE 

MAXIMUM  EXECUTION  TIME: 

RELATED  MODULES 

(List) 
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TAB  E 


FUTURE  WORK  SUGGESTIONS 


The  following 
consideration, 
improving  the 
computer  system 


suggestions  for  future  work  are  presented  for  ESD/'TOT 
The  suggestions  are  directed  towards  using,  updating,  and 
procedures  presented  in  this  handbook,  for  estimating 
sizing  and  timing  parameters. 


1.  Encourage  the  use  of  the  handbook  by  ESD/TOI  engineers  and  computer 
scientists. 

2.  Conduct  training  classes  in  the  use  of  the  handbook. 

3.  Establish  an  ESD/TOI  repository  of  sizing  and  timing  studies  performed 
by  Program  Offices  and  ESD/TOI. 

4.  Establish  the  capability  for  converting  the  results  of  sizing  and 
timing  studies  into  a  uniform  accessible  data  base. 

5.  Based  on  the  sizing  and  timing  data  acquired  through  the  repository 
and  data  base,  validate  and  expand  the  metrics  and  information 
presented  in  this  volume  of  the  handbook. 

6.  Ensure  the  continued  viability  of  the  handbook  through  subsequent 
enhancement  of  the  scope  of  the  procedures  and  techniques  based  on 
actual  application. 
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ANNOTATED  BIBLIOGRAPHY 


This  Annotated  Bibliography  presents  abstracts  of  some  of  the  more 
relevant  documents  cited  in  the  Bibliography  in  Volume  I  of  this  handbook. 


1.  Beizer,  Boris,  Micro-Analysis  of  Computer  System  Performance,  Van 
Nostrand  Reinhold  Company,  New  York,  1978. 

Abstract 

The  author  presents  his  subject  with  two  main  objectives.  First,  to 
discuss  how  performance  analysis  could  be  accomplished  on  a  simple 
computer  system  or  a  segment  of  a  large  computer  system.  Second,  to 
introduce  techniques  for  accomplishing  such  analyses.  Performance 
measures  and  parameters  are  discussed,  followed  by  a  presentation  of  an 
evaluation  technique,  which  the  author  calls  a  first  cut  performance 
analysis.  The  approach  encompasses  some  mini-max  relationships  that  could 
prove  of  value  when  more  accurate  approaches  could  not  be  utilized  due  to 
the  lack  of  adequate  data.  In  addition,  timing  and  systems  analysis  are 
also  discussed. 

Keywords 

performance  analysis,  performance  measures,  techniques,  timing 


2.  Bell,  C.  G.,  et  al.,  Computer  Engineering;  A  DEC  View  of  Hardware 
Systems  Design,  Digital  Press,  Bedford,  Mass.,  September  1978. 

Abstract 

The  book  presents  a  case  study  approach  that  examines  thirty  Digital  Equip¬ 
ment  Corporation  (DEC)  computers  developed  by  the  company  over  the  past 
twenty  years.  Various  aspects  of  DEC  hardware  designs  are  discussed,  and 
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improvements  over  the  years  in  access  time,  memory  size,  transfer  rates, 
performance,  etc.,  are  illustrated  in  graphs.  The  authors  state  that 

performance  parameters  are  a  combination  of  architecture  (the  instruction 
set  processor),  the  hardware  implementation,  and  the  resources  (the 
processor -memory-switch)  being  acted  on  by  the  programs  (the  use).  In 

addition,  they  comment  that  simplistic  hardware  measures,  such  as 
instruction  times,  can  be  used  to  characterize  machine  performance  for 

many  cases.  However,  the  ultimate  performance  has  to  be  based  on  actual 
use  parameters,  otherwise  there  is  no  way  to  correlate  the  primitive 

hardware  measures  to  real  performance. 

Keywords 

Access  Time,  architecture,  hardware  measurements,  memory  size, 
performance,  transfer  rates 


3.  Bourdon,  Gerard  A.,  Duquette,  Joseph  A.,  A  Computerized  Model  for  Esti¬ 
mating  Software  Life-Cycle  Costs  (Model  Concept),  ESD  Hanscom  AFB , 
Report  No.  ESD-TR-77-253 ,  Vol.'  I,  April  1978.  AD/A-053-937 

Abstract 

This  report  is  the  first  volume  of  a  series  of  reports  on  the  development 
of  a  computerized  model  for  estimating  software  life-cycle  costs.  This 
volume  deals  with  the  basic  concepts  of  the  model.  The  report  defines  the 
models  basic  stages,  the  methodologies  employed,  and  the  desired  features. 
The  report  contains  information  on  operating  the  model  by  manual  methods. 
The  first  stage  of  the  modei,  sizing,  transforms  software  functional 

requirements  into  estimates  of  computer  program  size.  It  relies  on 
results  obtained  by  Doty  Associates,  Inc.  (DAI)  in  their  software  cost 

estimation  study  for  RADC ;  e.g. ,  relating  software  memory  size  (words  of 

object  code)  to  software  characteristics  (application,  number  of  major 

functions)  and  hardware  parameters  (word  size,  processor  cycle  time) . 
Similarly,  the  other  stages  of  the  model  (manpower,  schedule,  manloading, 
and  cost)  are  also  derivations  from  previous  results  obtained  by  DAI  as 
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well  as  U.  H.  Putnam  (life-cycle  manloading).  The  importance  of  software 
sizing  in  estimating  project  resource  requirements  is  evident  in  this 
model. 


Keywords 

cost,  estimates,  functions,  LCC,  manloading,  modeling,  scheduling,  sizing, 
software 


4.  Boyse,  J.  W.  ,  Irani,  K.  B.,  Uppal,  I.  S.,  et  al..  Study  of  Information 
in  Multiple-Computer  and  Multiple-Console  Data  Processing  Systems, 
Michigan  University,  Annual  Report  #4,  Report  No.  RADC-TR-07 1-160 , 
August  1971.  AD/A-729-194 

Abstract 

A  portion  of  this  report  discusses  the  application  of  operations  research 
techniques  to  the  general  problem  of  optimization  of  multiprogrammed, 
multiprocessor  computer  systems.  The  analysis  procedure  itself  is 
computerized.  The  paper  is  principally  concerned  with  estimation  and 
control  of  timing  parameters  through  investigation  of  software  module 
execution  priorities,  software/hardware  tradeoffs,  parallel  processing, 
and  storage  hierarchies. 

The  mathematical  model  developed  by  the  authors  accommodates  effects  of 
user  program  behavior,  operating  system  characteristics,  and  hardware 
performance.  It  can  be  employed  as  an  investigation  tool  for  analyzing 
computer  systems  in  general  or  for  detailed  analysis  of  a  particular 
system.  The  model  could  also  be  used  in  optimizing  computer  systems. 
According  to  the  authors,  the  results  of  their  model  closely  approximates 
those  obtained  from  simulation  models. 

The  model  requires  information  on  the  user  programs  (including  estimated 
size),  storage  device  descriptions,  and  data  traffic  dependencies  and 
architecture.  Model  output  is  system  performance  (mean  program  execution 
rates,  queue  lengths,  CPU  utilization). 
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The  paper  contains  detailed  consideration  of  topics  such  as  task  sched¬ 
uling,  data  structures,  and  hardware  characteristics.  Full  description  of 
the  model  is  contained  in  another  paper  (Analysis  and  Optimization  of 
Multiprograraned  Computer  Systems  Using  Storage  Hierarchies,  A.M.  Woolf) . 

Keywords 

configuration,  hardware,  memory,  modeling,  performance,  real-time,  soft¬ 
ware,  storage,  timing 


5.  Capps,  L.  R.  ,  Software  Management  and  the  Testing  of  Weapons  Systems 
that  Contain  an  Embedded  Computer  System,  Defense  Systems  Management 
College,  Student  Report  No.  75-2,  November  1975.  AD/A-026-556 

Abstract 

This  report  presents  an  overview  of  the  Department  of  Defense  Weapon  Sys¬ 
tem  Software  Management  Program.  Specifically,  the  program  is  examined 
from  the  point  of  view  of  the  testing  requirements  associated  with  the 
development  of  weapon  systems  that  contain  embedded  computer  systems.  The 
thrust,  as  presented  in  the  report,  is  the  evolution  from  software 
development  as  an  art  to  software  development  as  a  science. 

Useful  portions  of  the  report  deal  with  the  attributes  of  embedded  sys¬ 
tems,  a  model  of  the  system  development  phases,  and  an  excellent  descrip¬ 
tion  of  the  software  verification  process. 

Keywords 

embedded  computer  systems,  management,  modeling,  software,  testing,  veri¬ 
fication,  weapon  systems 
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6.  Carey,  L.  j.  ,  Hirschf  ieid,  G.  A.,  Tucker ,  A.  E.  ,  et  al.  ,  Survey _ ~.f 

Scf  iware  Techn  iques _  Spacefccrne  Software  Systems  Study,  System 

Development  Torpor at:  n,  Report  No.  SSD-TR-67-11,  Vcl.  TV,  tanuary 
1967.  AD-807-400 

Abstraet 

This  report  reviews  software  and  the  software  development  process  as  they 
apply  to  satellite  systems.  Among  other  things,  it  briefly  discusses 
sizing  and  timing  tradeoff  techniques;  e.g. ,  methods  by  which  more 
software  or  data  storage  space  is  given  up  in  order  to  achieve  higher 
processing  speed.  An  algorithm  is  given  for  allocation  of  storage  space, 
given  subprogram  size  and  operating  time.  Methods  for  estimating  time 
P3"ameters  during  program  testing  are  outlined. 

Keywords 

memory,  module,  procedures,  real-time,  sizing,  software,  storage,  timing 

7.  Drummond,  Mansford  E.  ,  Jr.,  Evaluation  and  Measurement  Techniques  for 
Digital  Computer  Systems,  Prentice  Hall,  Inc.,  Englewood  Cliffs,  N.J., 
197  3. 

Ab  s  t  r  ac  t 

The  book  discusses  the  evaluation  of  CPU  performance  and  system  perfor¬ 
mance,  simulation  techniques,  systems  analysis  techniques,  programmed 
measurement  techniques,  as  well  as  instrumented  measurement  techniques. 
The  author  also  discusses  hew  and  when  to  use  various  evaluation  tech¬ 
niques.  Of  primary  relevance  to  this  handbook  are  the  discussions  of 
systems  analysis  techniques  that  are  identified  as  the  simpler  techniques 
that  involve  determination  of  throughput  and/or  response  time  attributes. 

Keywords 

performance  evaluation,  system  performance,  systems  analysis,  techniques 


8.  Embedded  Computer  Resources  and  the  DSARC  Process  -  A  Guidebook,  Office 
of  the  Secretary  of  Defense,  1977.  AD/A-046-398 

Abstract 

This  guidebook  covers  salient  embedded  computer  resource  issues  in  the 
context  of  the  Defense  System  Acquisition  Review  Council  (DSARC)  process. 
The  guidebook  is  divided  into  five  sections:  (1)  the  first  section  dis¬ 
cusses  general  DSARC  issues  and  provides  guidelines  to  determine  adequacy 
of  computer  resource  utilization  and  planning.  The  section  also  provides 
a  list  of  questions  to  guide  OSD  personnel  in  their  evaluation  of  embedded 
computer  resources  at  each  DSARC  meeting;  (2)  the  second  section  discusses 
sensitivity  data  and  relationships  and  reviews  some  twenty-five  factors 
and  their  relationship  to  productivity;  (3)  the  third  section  discusses 
program  inquiry  questions  and  suggests  several  replies  that  cover  general 
background,  software  estimating,  and  programming  practices;  (4)  the  fourth 
section  provides  guidelines  for  software  estimating;  and  (5)  the  final 
section  contains  a  list  of  reference  documents  covering  policy,  practice, 
and  procedures. 

Keywords 

acquisition,  cost,  embedded,  estimates,  procedures,  productivity,  regula¬ 
tions 


9.  Ferrari,  Domenica,  Computer  Systems  Performance  Evaluation,  Prentice- 
Hall,  Inc.,  Englewood  Cliffs,  N.J.,  1978. 

Abstract 

Developed  as  a  course  book  for  computer  science  seniors  and  first-year 
graduate  students,  the  author  discusses  performance  evaluation  of  computer 
systems  from  a  macro-analysis  approach,  as  well  as  from  an  overview  of  the 
subject  matter.  Techniques,  viewpoints  and  approaches  that  the  author 
considered  as  becoming  more  viable  in  the  near  future  are  presented. 
Measurement  tools,  analytic  modeling  and  workload  characteristics  are 
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discussed,  as  are  computer  selection,  performance  improvement,  and  perfor¬ 
mance  evaluation  in  computer  system  design.  In  addition,  evaluation  of 
program  performance  is  also  discussed.  The  author's  treatment  of  the 
multitude  of  complexities  and  diversified  views  of  the  various  aspects  of 
computer  system  performance  evaluations  and  its  numerous  parameters  are  of 
particular  interest. 

Keywords 

analytic  modeling,  computer  selection,  computer  system,  measurement  tools, 
performance  evaluation,  performance  improvement,  program  performance 
evaluation,  workload  characteristics 


10.  Flynn,  Michael  J.,  Studies  in  the  Organization  of  Computer  Systems, 
1977  Progress  Summary,  Digital  Systems  Laboratory,  Stanford  University 
Technical  Note  No.  121,  November  1977. 

This  project  report  discusses  various  research  activities  into  theoretical 
and  practical  methods  for  categorization,  analysis  and  synthesis  of  com¬ 
puter  systems.  Of  particular  interest  is  their  analytical  modeling  of 
certain  types  of  parallel  machine  performance.  Their  model  distinguished 
the  differences  between  logical  parallelism  in  terms  of  available  proc¬ 
esses  and  the  physical  parallelism  (the  p  processors)  available  in  a 
computer  organization.  This  analysis  demonstrated  the  dependency  of 
performance  bounds  on  both  the  computation  being  executed  and  the  computer 
architecture.  The  report  notes  that  the  analysis  demonstrated  that 
necessary  and  sufficient  conditions  for  a  maximum  attainable  speedup  of  p 
parallel  processors  over  a  uniprocessor  would  be  sped  up  less  than  p/lnp 
as  long  as  the  logical  parallelism  exceeded  the  number  of  physical 
processors  available  in  the  program.  The  conditions  that  establish 
validity  are  based  on  certain  artifacts  of  control  in  parallel  programs. 
The  author  states  that  their  results  were  consistent  with  Mr.  D.  Kuck's 
study  at  the  University  of  Illinois. 
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Keywords 

modeling,  parallel  processors,  performance,  uniprocessors 


11.  Graver,  C.  A.,  et  al. ,  Cost  Reporting  Elements  and  Activity  Cost  Trade¬ 
offs  for  Defense  System  Software  -  Study  Results,  General  Research 
Corporation,  Report  No.  ESD-TR-77-262 ,  Vol.  I,  11  May  1977. 
AD/A-053-020 

Abstract 

This  paper  surveys  software  cost  estimating  techniques  as  they  are  appli¬ 
cable  to  the  acquisition  cycle.  A  "process  model  of  software  development" 
is  proposed  that  is  based  on  interviews  with  Air  Force  SPO's  and  on  AFR 
800-14.  The  resulting  model  is  not  fully  in  accord  with  AFR  800-14  but 
may  be  a  more  useful  basis  for  software  size  estimating  in  that  it  recog¬ 
nizes  the  interdependencies  among  the  development  phases.  Detailed  des¬ 
criptions  of  activities  in  each  phase  are  given. 

*  This  paper  advocates  use  of  object  code  size  as  a  metric  for  some  phases 
of  software  acquisition  and  source  code  for  others  (most  importantly,  the 
coding  and  checkout  phase) .  Effects  of  language  and  hardware  specifica¬ 
tions  are  recognized.  Expansion  ratios  for  COBOL,  JOVIAL,  and  FORTRAN  are 
given  for  several  software  packages  on  various  computers. 

The  report  describes  in  very  summary  form  a  software  sizing  procedure.  It 
involves  categorizing  required  software  by  type,  considering  software  com¬ 
plexity,  and  applying  size  estimating  techniques  (none  included) . 

Keywords 

acquisition,  complexity,  cost,  cost  estimating  relationships,  estimates, 
modeling,  procedures,  productivity,  regulations,  schedule,  sizing, 
software,  techniques 
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TR-75-85 ,  Vol.  I,  September  1975.  AD/A-016-488 


Abstract 

This  guidebook  provides  information  for  managers  and  technical  personnel 
engaged  in,  or  planning  for,  the  monitoring  and  .reporting  of  the  technical 
status  of  a  software  development  project.  It  reflects  the  acquisition 
life-cycle  as  presented  in  AFR  800-2. 

Tools  for  monitoring  development  are  reviewed.  A  statement  of  new  soft¬ 
ware  methodologies  and  their  effect  on  management  visibility  is  also 
presented. 

Keywords 

acquisition,  monitoring,  performance,  regulations,  software 

13.  Halstead,  Maurice,  H.,  Elements  of  Software  Science,  Elsevier  North- 
Holland,  Inc.,  New  York,  1977. 

Abstract 

This  study  presents  an  approach  to  software  sizing  based  on  the  applica¬ 
tion  of  principles  of  natural  science.  It  attempts  to  relate  the  process 
of  producing  computer  instructions  (and,  more  broadly,  language  prose)  to 
much  more  basic  processes  of  human  cognition.  For  each  hypothesis  posed, 
the  paper  describes  carefully  designed  empirical  studies  of  the  author  or 
others  that  support  it.  A  number  of  factors  are  described  that,  if 
accepted,  provide  a  comprehensive  foundation  for  understanding  the  process 
of  software  development  and  how  it  is  affected  by  such  things  as  program¬ 
mer  capability,  language  employed,  and  nature  of  the  problem  to  be  solved 
by  computer. 

The  author  argues,  for  example,  that  a  lower  bound  is  established  for  the 
effort  to  prepare  a  particular  software  algorithm  only  if  the  problem  is 
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well-stated  (and  well-understood  by  the  programmer) ,  the  programmer  is 
fluent  in  the  language  employed,  and  the  programmer  applies  full  mental 
concentration  to  the  effort.  If  any  of  these  conditions  is  not  fully  met, 
greater  effort  is  required  to  successfully  develop  the  software.  One 
dimension  of  effort  is  size  of  the  software. 

Judging  from  the  literature,  Halstead's  work  is  not  now  widely  familiar  or 
accepted.  It  seems  probable,  however,  that  this  approach  to  understanding 
the  process  of  software  development,  because  of  its  basis  in  fundamental 
human  reasoning  abilities,  will  prove  to  be  far  more  powerful  than  current 
empirical  methods. 

Keywords 

empirical  studies,  estimates,  instructions,  languages,  modeling,  proced¬ 
ures,  programmer  capability,  sizing,  software,  techniques 


14.  Herd,  J.  H.  ,  Postak,  J.  N.  ,  Russell,  W.  E.  ,  Stewart,  K.  R. ,  Software 

Cost  Estimation  Study  -  Study  Results-Final  Report,  Doty  Associates, 
Inc.,  Report  No.  RADC-TR-77-220 ,  Vol.  I  (with  Errata),  February  1977. 
AD/A-042-264 

Doty,  D.  L. ,  Nelson,  P.  J.,  Stewart,  K.  R. ,  Software  Cost  Estimation 

Study  -  Guidelines  for  Improved  Software  Cost  Estimating,  Doty  Asso¬ 
ciates,  Inc.,  Report  No.  RADC-TR-77-220,  Vol.  II  (with  Errata),  Feb¬ 
ruary  1977.  AD/A-044-609 

Abstract 

This  report  discusses  general  software  size  estimating  procedures  and 

requirements.  It  emphasizes  the  importance  of  careful  initial  design  and 
advocates  the  preparation  of  a  software  work  breakdown  structure  to  reduce 
estimating  errors. 


Several  size  estimating  techniques  are  included  that  were  statistically 
developed  from  data  in  the  literature  and,  based  on  their  correlation 
coefficients,  are  not  particularly  precise  estimators.  Two  estimating 
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relationships  give  number  of  lines  of  source  code  as  a  function  of  soft¬ 
ware  functions,  hardware  characteristics,  and  application  type.  Another 
estimator  relates  required  core  size  to  software  and  processor  character¬ 
istics  and  type  of  application. 

For  analogy  sizing,  an  estimator  is  developed  that  relates  software  size 
of  a  new  program  to  that  of  an  analogous  program,  the  number  of  major 
types  of  functions  to  be  performed  by  the  new  software,  and  the  number  of 
functions  performed  by  the  analogous  program.  Also,  an  algorithm  for  con¬ 
verting  from  object  code  estimates  to  source  code  estimates  is  given  as  a 
function  of  the  expansion  ratio  and  the  language  mix. 

Keywords 

cost,  cost  estimating  relationships,  estimates,  hardware,  memory, 
procedures,  productivity,  schedule,  sizing,  software,  techniques 


15.  Information  Processing/Data  Automation  Implications  of  Air  Force 
Command  and  Control  Requirements  in  the  1980s  (CCIP-85)  (U)  ,  Volume 
IV,  Technology  Trends  -  Software,  SAMSO  TR  72-122,  October  1973. 
AD-919-267 

Abstract 

The  study  report  is  one  of  several  reports  prepared  in  the  CCIP-85  study 
effort.  The  objective  of  the  CCIP-85  study  was  to  examine  the  functions 
to  be  performed  by  future  Command  and  Control  systems  and  assess  what  new 
functions  must  be  performed  by  the  computer  software  and  hardware.  Volume 
IV  of  the  study  report  discusses  requirements,  future  capabilities  poten¬ 
tial,  and  associated  potential  problem  areas.  The  report  also  outlines 
promising  RSD  strategies  to  resolve  the  differences  between  future  Command 
and  Control  requirements  and  future  software  technology. 

Keywords 

Command  and  Control,  future  capabilities,  hardware,  software 
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16.  Johnson,  L.  A.,  et  al. ,  "Automated  Analysis  of  System  Specifications," 
Second  U.S.  Army  Software  Symposium  (Proceedings),  U.S.  Army  Computer 
Systems  Command,  Williamsburg,  Va.,  25-27  October  1978,  pp.  235-258. 

Abstract 

This  paper  describes  an  automated  Air  Force  technique  for  qualifying  sys¬ 
tem  requirements,  where  system  is  defined  broadly  as  a  collection  of 
equipment,  personnel  resources,  capabilities  and  techniques  that  together 
perform  an  operational  role.  It  discusses,  among  other  things,  the 
derivation  of  discrete,  non-overlapping  requirements  and  the  structuring 
of  information  requirements  hierarchies.  The  methodology  provides  for 
linking  system  performance  requirements  to  specific  designs,  and  the  paper 
notes  that  relationships  exist  that  can  provide  a  link  between  require¬ 
ments  engineering  activities  and  subsequent  implementing  engineering, 
since  such  requirements  can  be  traced  from  functional-performance 
specifications  to  development  specifications  to  product  specifications  £  id 
system  test  activities  during  the  later  phases  of  the  system  acquisition. 

Keywords 

acquisition,  configuration,  hardware,  modeling,  quality,  performance, 
software  engineering,  systems 


17.  Kossiakoff,  A.,  et  al. ,  DoD  Weapon  Systems  Software  Management  Study, 
Johns  Hopkins  University  Applied  Physics  Laboratory,  APL/JHU  SR  75-3, 
June  1975. 

Abstract 

This  report  presents  the  results  of  a  study  conducted  by  the  Applied  Phy¬ 
sics  Laboratory  of  the  Johns  Hopkins  University  in  conjunction  with  the 
MITRE  Corporation.  The  purpose  of  the  study  and  the  resultant  report  cen¬ 
tered  on  the  problems  associated  with  the  acquisition  of  weapon  systems 
containing  and/or  driven  by  extensive  software  programs.  Seventeen  recom¬ 
mendations  are  provided  that,  if  implemented,  could  be  of  great  value  in 
reducing  cost  and  schedule  problems  associated  with  large  systems. 
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Two  useful  features  provided  by  the  report  are:  1)  system  configuration 
descriptions  and  associated  histories  of  selected  weapon  systems,  and 
2)  discussions  by  several  major  software  development  organizations  as  to 
the  problems  of  system  development  and  recommended  solutions.  The  major 
problem  is  indicated  to  be  the  lack  of  system  definition  as  supported  by 
initial  requirement  analysis. 

Keywords 

acquisition,  procedures,  requirements  analysis,  system  configurations, 
software  engineering,  system  developments,  weapon  systems 


18.  Rosy,  Donald  W. ,  Air  Force  Command  and  Control  Information  Processing 
in  the  1980s:  Trends  in  Software  Technology,  The  Rand  Corporation, 
Report  No.  R-1012-PR,  Vol.  I,  June  1974.  AD/A-017-128 

Abstract 

This  report  discusses  software  trends  in  the  Air  Force  Command  and  Control 
systems  in  the  1970's  and  1980's.  The  state-of-the-art  of  software  tech¬ 
nology,  as  it  existed  in  1972,  is  discussed  and  forecasts  changes  in 
technology  over  the  next  fifteen  years.  Comparisons  are  made  between 
projected  Air  Force  requirements  and  software  technology.  Future  improved 
software  qualitative  requirements  are  considered  to  be  vital  in  Air  Force 
Command  and  Control  systems.  The  software  technology  forecasts  were 
projected  based  on  historical  developments  and  technological  trends.  it 
was  noted  that,  unlike  hardware  forecasting,  software  forecasting  was 
difficult  because  there  was  no  firm  data  base  from  which  to  project. 
However,  projections  were  made  in  the  area  of  software  functions  and 
methods  of  design,  production  and  validation.  Finally,  future  software 
technology  capabilities  estimates  were  compared  with  the  projected 
software  requirements. 

Keywrds 

C^,  hardware,  language  sizing,  software,  software  development,  trends 
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19.  Lehman,  John  H. ,  Thayer,  Richard  H. ,  Software  Engineering  Project  Man¬ 
agement:  A  Survey  Concerning  U.S.  Aerospace  Industry  Management  of 

Software  Development  Projects  (Interim  Report),  Sacramento  Air  Logis¬ 
tics  Center/ACD,  Report  No.  ACD  TR-77-02,  November  1977.  AD/A-050-802 

Abstract 

This  paper  gives  certain  summary  findings  from  a  survey  of  18  aerospace 
companies  engaged  in  software  development  efforts.  Although  not  directly 
relevant  to  sizing  and  timing  estimation,  the  report  does  provide  informa¬ 
tion  on  the  environment  in  which  past  software  development  efforts  were 
conducted.  For  example,  approximately  equal  numbers  of  the  projects  in 
the  sample  began  with  little  or  no  specifications,  moderately  complete 
specifications,  or  highly  detailed  specif ications.  The  percentage  of 
specification  rewrite  required  during  the  project  was  directly  propor¬ 
tional  to  the  degree  of  initial  specification.  A  number  of  constraints 
were  placed  on  various  development  efforts,  including  specified  hardware, 
storage  limitations,  speed  requirements,  and  budget  and  schedule  limits. 
Certain  software  development  management  practices  are  also  summarized. 

Keywords 

cost,  estimates,  hardware,  procedures,  quality,  schedule,  software, 
software  development,  specifications 


20.  Martin,  James,  Design  of  Real-Time  Computer  Systems,  Prentice-Hall, 
Inc.,  Englewood  Cliffs,  New  Jersey,  1967. 

Abstract 

This  book,  one  of  the  Prentice-Hall  Series  in  Automatic  Computation,  is  an 
excellent  treatise  on  the  design  of  real-time  systems.  Of  particular 
utility  are  the  chapters  that  discuss  estimating  program  size,  system 
timing,  and  core  storage  requirements.  These  chapters  provide  sets  of 
procedures  that  are  generally  directed  toward  the  end  of  including  all 
factors  in  the  estimating  process  that  may  cause  the  greatest  penalty  if 
ignored.  In  addition,  the  book  discusses  the  problems  of  design  of 


-■-TT 


TT 


ANBIBLIO-14 


real-time  systems,  calculations  and  estimating  techniques,  and  reasons  for 
incorrect  estimates. 


Keywords 

C3,  estimating,  real-time,  reliability,  sizing,  storage,  techniques, 
timing 


21.  Matick,  Richard,  Computer  Storage  Systems  &  Technology,  John  Wiley  & 
Sons,  Inc.,  New  York,  1977. 

Abstract 

This  book  discusses  memory  and  Storage  technology.  A  history  of  the 
change  in  size,  timing  elements,  and  types  of  storage  systems  is 
explored.  The  uses  of  primary  and  secondary  memory  system  are  discussed. 
Fundamen-  tal  principles  of  memory  and  storage  parameters  and  architecture 
are  presented.  Random  access  methods,  magnetic  characteristics  of 
recording  medium,  sequential  access  methods,  direct  access  methods,  file 
organiza-  tion,  data  structures,  memory  hierarchies,  and  virtual  memory 
are  discussed  in  detail. 

Keywords 

configuration,  hardware,  memory,  performance,  sizing,  storage 


22.  Navarro,  Aaron  B. ,  Romanczuk,  Ronald  J.,  Imbedded  Software  Monitors 
and  Data  Collection  -  Design  and  Implementation,  PRC  Information 
Sciences  Company,  Report  No.  RADC-TR-74-217 ,  Vol.  I,  September  1974. 
AD-787-672 

Abstract 

This  paper  describes  a  software  monitoring  procedure  that  is  used  to 
measure  timing  parameters  (e.g. ,  CPU  time,  I/O  time)  of  program  modules. 
The  information  could  assist  in  determining  frequency  routines,  time  and 
storage  requirements.  Regressions  were  run  on  data  collected  using  the 
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monitoring  system  on  a  data  management  system  software  package.  Equations 
for  record  retrieval  I/O  time,  CPU  time,  and  number  of  reads  were  derived 
as  functions  of  file  size,  page  size,  and  number  of  buffers  used. 

Keywords 

estimates,  hardware,  modeling,  module,  performance,  sizing,  software, 
techniques,  timing 


23.  Neil,  George,  Software  Acquisition  Management  Guidebook:  Reviews  and 
Audits,  System  Development  Corporation,  Report  No.  ESD-TR-78-117 , 
November  1977.  AD/A-052-567 

Abstract 

This  report  combines  existing  guidance  regarding  reviews  and  audits  cur¬ 
rently  contained  in  a  number  of  different  official  documents  and  narrows 
the  focus  of  editing  guidance  to  those  problems  inherent  in  software 
acquisition  management.  Engineering  design  reviews  and  configuration 
management  audits  are  broken  down  into:  (1)  materials  to  be  reviewed,  (2) 
requirements,  and  (3)  post-review  activities. 

The  section  on  reviews  and  audits  problem  areas  identifies  some  of  the 
more  common  problems  created  by  improper  implementation  of  reviews  and 
audits  requirements.  In  addition,  it  discusses  how  engineering  design 
reviews  can  be  used  to  prevent  other  common  and  serious  problems. 

Keywords 

acquisition,  audits,  design  configurations,  management,  performance, 
regulations,  requirements,  reviews,  software 
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24 .  Operational  Software  Management  and  Development  for  U.S.  Air  Force 
Computer  Systems,  National  Academy  of  Sciences,  National  Research 
Council,  Air  Force  Studies  Board,  Washington,  D.C.,  1977. 

Abstract 

The  report  presents  the  results  of  a  1976  Air  Force  Studies  Board  study 
that  was  concerned  with  the  operational  management  and  development 
primarily  during  the  acquisition  life-cycle  of  U.S.  Air  Force  embedded 
computer  resources.  The  study  examined  management  approaches  as  applied 
in  1976  and  suggests  several  approaches  that  the  Air  Force  might  employ  to 
develop  operational  software  for  Embedded  Computer  Systems  (ECS) .  The 
first  problem  cited  was  that  detail  requirements,  especially  extreme 

conditions  and  collateral  tasks,  are  not  delineated  in  the  Required  Opera¬ 
tional  Capability  (ROC)  documents,  the  Program  Management  Directive  (PMD) 
or  even  the  System  Specification.  As  a  result  of  these  inadequacies, 
there  is  subsequent  need  to  redesign  and  redo  the  software,  not  only 

throughout  the  acquisition  life-cycle  phases,  but  also  into  the  Operations 
and  Maintenance  Phase.  The  second  major  problem  cited  pertained  to  the 
inadequate  involvement  of  the  user  and  the  maintainer  organizations 
throughout  the  entire  acquisition  life-cycle.  The  consequences  are 
similar  to  those  cited  in  the  first  problem  area.  The  third  problem  area 
suggested  by  the  study  group  was  the  one-of-a-kind  philosophy  of 
development.  That  is,  each  software  development  is  considered  a  one  time, 
specific  development  when  actually  there  can  be  a  considerable  number  of 
aspects  of  one  development  that  could  be  beneficially  applied  to  other 
developments.  Also,  there  appears  to  be  a  distinct  break  in  organiza¬ 

tions'  responsibilities,  particularly  between  the  acquisition  life-cycle 
and  the  operations  and  support  phase.  The  study  group  suggests  an 

overlapping  of  the  development  organizations  und  the  maintenance 
organization  to  develop  a  sense  of  continuity. 

Keywords 

acquisition  life-cycle,  embedded  computer  resources,  embedded  computer 
systems,  management  approaches,  software  development 
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25.  Roberts,  Alan  J.  ,  Command  and  Control  System  Acquisition:  Software  Im¬ 
plications,  User/Developer  Interface,  AIIE  Conference  on  Electronic 
System  Acquisition  Management,  Washington,  D.C.,  25-27  April  1979. 

Abstract 

This  document  was*  prepared  for  the  AIIE  Conference  on  Electronic  System 
Acquisition  Management.  The  author  describes  the  distinguishing 
characteristics  of  C3  systems  and  the  special  problems  they  present  to 
users  and  developers  during  the  acquisition  process.  Various  acquisition 
approaches  are  discussed  that  should  improve  the  chances  for  a  successful 
delivery  of  a  C3  system  with  the  required  capabilities.  The  focus 
throughout  is  on  two  characteristics  of  C3  systems:  software  domination 
and  user  involvement.  The  conviction  is  .xpressed  that  one  cannot  produce 
adequate  specifications  or  make  satisfactory  cost  estimates  without  first 
actually  performing  some  part  of  the  task  to  be  specified  and  estimated. 

From  the  standpoint  of  sizing  and  timing,  the  author  makes  the  observa¬ 
tion  that  in  practically  every  program,  machine  resources  are  overcom¬ 
mitted,  both  in  response  time  and  memory.  Early  estimates  of  hardware 
requirements  are  rarely  applied,  whereas  funding  limitations  are  imposed 
on  software  development.  The  author  suggests  that  major  fund  commitments 
should  not  be  made  before  appropriate  hardware/software  tradeoffs  have 
been  accomplished.  Inadequacies  of  C3  hardware  resources  should  be 
rectified  by  adding  more  hardware  rather  than  by  trying  to  revise  the 
software.  In  weapons  systems,  however,  where  space  and  weight  are 
specific  constraints,  a  different  approach  may  be  required.  Generally, 
the  amount  of  spare  memory  capacity  (25-30%)  is  used  up  in  the  development 
of  the  software.  The  author  suggests  that  spare  memory  capacities  of 
100-200%  might  be  considered  to  reduce  many  software  development  and 
subsequent  maintenance  problems.  In  addition,  visibility  and  control  of 
storage  and  response  time  should  be  maintained  and  should  aid  in  resolving 
conflicts. 
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acquisition,  C3  systems,  hardware  requirements,  memory,  memory  capacity, 
response  time,  software  engineering,  tradeoffs 


26.  Smith,  Ronald  L.  ,  Estimating  Software  Project  Resource  Requirements  - 
Structured  Programming  Series,  IBM  Corporation,  Report  No.  RADC-TR- 
74-300,  Vol.  XI,  January  1975. 

Abstract 

This  report  deals  with  software  development  resource  estimating  in  a 
structured  programming  environment.  It  reviews  literature  pertinent  to 
software  cost  estimation  and  outlines  some  of  the  traditional  procedures. 
A  procedure  (model)  is  discussed  for  estimating  software  resources  on  the 
basis  of  similar  experience.  The  author  states  that  size  can  be  estimated 
on  the  basis  of  number  of  program  modules  times  the  average  estimated 
module  size. 

Keywords 

cost,  estimates,  module,  procedures,  productivity,  schedule,  size,  soft¬ 
ware,  systems 


27.  Svobodova,  L.  ,  Computer  Performance  Measurement  and  Evaluation  Methods: 
Analysis  and  Applications,  Volume  2  in  the  Computer  Design  and  Archi¬ 
tecture  Series,  Elsevier  Computer  Science  Library,  American  Elsevier 
Publishing  Co.,  Inc.,  New  York,  1976. 

Abstract 

This  book  develops  an  understanding  of  the  problem  of  performance  evalua¬ 
tion  and  shows  how  to  analyze  available  techniques  within  this  concept. 
The  book  is  divided  into  two  parts.  The  first  part  examines  fundamental 
concepts  and  the  second  examines  different  tools  and  techniques  in  detail. 
Fundamental  concepts  include  those  elements  of  computer  system  performance: 
system  workload  measures,  measurement,  and  analysis;  control  of  system 
performance;  and  qualitative  assessment  of  system  performance. 
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Basic  tools  and  techniques  include  system  models,  workload  models,  simula¬ 
tion,  and  measurement  tools.  To  these  must  be  added  the  question  of  meas¬ 
urability  as  discussed  later  in  the  book.  System  models  encompass 
structure,  function,  analysis,  and/or  experimentation  as  a  basis.  Work¬ 
load  models  include  instruction  mix,  benchmarks,  synthetic  benchmarks, 
trace,  probabilistic  workload  models,  and  interactive  system  drivers. 
Simulation  is  either  stochastic  or  trace  driven.  Common  measurement  too_s 
discussed  are  performance  monitor,  software  and  hardware  monitors,  and 
hybrid  monitors.  Measurement  tools  are  discussed  with  emphasis  on  both 
their  strengths  and  limitations. 

Finally,  the  question  of  measurability  is  addressed  separately.  Such 
issues  as  privacy,  environment,  data  acquisition,  monitoring  aids,  and 
automatic  control  of  system  performance  are  addressed. 

Keywords 

benchmarks,  complexity,  estimating,  hardware,  measuring,  memory,  metrics, 
modeling,  performance,  productivity,  sizing,  storage,  timing 


28.  Turn,  R. ,  Sine,  B.,  Air  Force  Command  and  Control  Information  Process¬ 
ing  in  the  1980 's:  Trends  in  Hardware  Technology,  The  RAND  Corpora¬ 
tion,  Report  No.  R-1001-PR,  Vol.  V,  October  1972.  AD-907-626 

Abstract 

This  report  discusses  hardware  trends  in  the  period  of  the  1970's  into  the 
1980's.  Sizing  and  timing  constraints  of  hardware  and  software  are 
reviewed  and  measured  against  expected  changes  in  the  1980 's. 

It  is  stated  that  emphasis  should  be  placed  more  on  good  Higher-Order 
Language  (BOL)  programming  because  sizing  and  timing  will  be  less  of  a 
constraint  and  BOL  tends  to  have  fewer  errors  per  function.  The  need  for 
Machine  Oriented  Language  (MOL)  programming  will  be  reduced  since 
solutions  to  hardware  problems  are  being  implemented  as  part  of  the 


ANBIBLIO-20 


hardware  itself.  Projections  are  presented  for  mass  memory  and  timing 
performance  into  the  90' s.  A  timing  metric  is  discussed,  and  processor 
characteristics  are  described  at  length. 

is  discussed  by  environmental  class  as  being  ground  based,  airborne, 
or  spaceborne.  Measures  of  performance  for  airborne  software  are  pre¬ 
sented. 

Keywords 

C^,  environment,  hardware,  language,  memory,  metrics,  performance, 
sizing,  software,  timing,  trends 


29.  Welch,  Terry  A.,  "Analysis  of  Memory  Hierarchies  for  Sequential  Data 
Access,"  Computer ,  Vol.  12,  No.  5,  May  1979,  pp.  19-26. 

Abstract 

This  paper  discusses  techniques  available  for  making  size/speed  tradeoffs 
between  core  and  various  external  memory  devices.  An  analytical  model  is 
developed  that  deals  explicitly  with  the  transfer  of  various  quantities  of 
data  from  external  memory  devices,  each  of  which  has  a  particular 
probability  of  access,  size,  transfer  time,  and  storage  cost.  Analysis 
techniques  can  be  applicable  in  the  system  design  when  these  parameters 
can  be  estimated.  Results  of  the  analysis  demonstrate  the  value  of 
storage  hierarchies  from  a  cost-effectiveness  standpoint. 

Keyvords 

configuration,  cost,  hardware,  memory,  modeling,  performance,  real-time, 
sizing,  software,  storage,  techniques,  timing 
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